> Btw, I think I read somewhere that groff never ever hyphenates
> the last word on a page. Is that true? I guess that makes the
> guys over at comp.text.tex envious. There are quite a few
> threads about how to make TeX & Children succeed with that...!
Don't draw premature conclusions from this
> I'm printing the lyrics of a CD; I want it in 2-col; so I did
>
> .2c
> .nf
>
> I wanted groff to *not* join short lines but break long lines;
> Short lines were not joined, ok!
> But groff did not break the long lines :-))
> - Long lines in the first column invaded the second colu
> hmm.. yes, adding a macro to each line is really annoying..
> but the output, the indent in particular, is exactly what I expected!
After tinkering around a bit, I seem to have come up with a
compact version using input line count traps. You might wish
to add something like ".sp .5" or so in t
> Here it is, independent of the macro package.
>
> Werner
>
> ==
> .\" break -- no join
> .de BNJ
> . nr BNJ-dobreak 1
> . it 1 BNJ-break
> ..
> .
> .de /BNJ
> . nr BNJ-dobreak 0
> ..
> .
> .de BNJ-break
> . if \\n[BNJ
> > \l'\n(.l/1.25'
>
> This doesn't work correctly.
In Solaris troff it does, because that troff uses only 10 units
per point (100 units per em for a 10-point font), so it doesn't
encounter an arithmetic overflow when evaluating [line length
in units]*[units per em] as groff does with 1000 uni
> ... but classical troff doesn't have -r, so it should be
> ignored.
Well, that's not quite true. Classical troff did have "-r", but
the syntax was different:
-raN The number register whose (one-character) name is a is
set to N.
(from the NROFF/TROFF User's Manual, 1976)
_
> input line 6:check TL, AU, AS, AE, MT sequence
It appears that your Solaris installation uses the original "mm"
macros (not the groff ones) and therefore doesn't understand
"COVER" and "VERBON". Perhaps it might work if you used
groff -T ascii -mgm file.mm
___
> does anyone have any simple methods for placing the table of contents
> at the start of the output file ?
>
> I have done it manually with Postscript output and should be able to
> script that, but if anyone has other suggestions I would appreciate
> hearing from them.
I think manipulating the
To be honest, my method has been pretty much obsoleted by
groff's "write" requests. It had been based on the fact
that troff had had no capability for writing larger blocks
of text (i.e., multi-line chunks) to external files.
Here is a toy model of a much better approach. Just roff
the file twi
> since a diversion isn't paginated until it is flushed out,
> how would we capture TOC entries, with proper page number
> references, while collecting the main body diversion?
Simple: you create a temporary page diversion for collecting
text. When that is full, you increment your own page cou
> >> since a diversion isn't paginated until it is flushed out,
> >> how would we capture TOC entries, with proper page number
> >> references, while collecting the main body diversion?
> >
> > Simple: you create a temporary page diversion for collecting
> > text. When that is full, you increm
> Can a diversion be spit out and fed to another one?
Yes, that's no problem. The only thing to keep in mind
when "replaying" one diversion into another is to do
this (normally) in no-fill mode, so as not to re-format
already-formatted material. If you want to save material
unformatted for form
> > > The problem with groff's `write' requests is that they
> > > don't work, if the user fails to specify the `-U' flag,
> > > when invoking groff.
> > >
> > > This flag activates the so called `unsafe' mode. While it
> > > probably isn't the case, this carries the connotation that
> > > it ma
[Replying to his message, I had mailed Jon directly instead of
the groff list. With his permission, I'm posting his reply here.]
> > > I do exactly what Werner is suggesting for my TOC, and it
> > > works out very well. My chapter and section macros write out
> > > title and page information to
> BTW, I *never* have *any* user writeable directory before the
> system binary directories, in *my* PATH; but, I guess it would
> be naive to expect everybody to follow that piece of simple
> security advice.
Obviously you're doing the Right Thing in this regard, but I
find it sometimes conveni
> > Here is a toy model of a much better approach. [...]
> >
> > (Note also that the technique is not really new -- LaTeX
> > has been using an analogous approach for a *long* time.)
>
> Indeed. It would be great if you can volunteer to
> add something like this to the ms macros.
Here is a si
Lots of fun with pie charts. Just for the heck of it, here's a
modified version of Ted's pie-chart mechanism that "remembers"
the angles of the wedges and allows you to give the wedge size
as a percentage of the whole "pie" (plus, it allows you to use
"groff" colors; the \N'32' (which should be a
This one works without string arguments:
.sp 3c
.de YY
ps: def
/wedge
{ gsave currentpoint translate 1 -1 scale
newpath 0 0 moveto 0 0 5 2 roll 3.6 mul exch
3.6 mul dup 3 1 roll add arc closepath
gsave fill grestore 0 setgray stroke
grestore }
def
..
\Y[YY]\c
.de wedge
\m[\\$2]\Z'\N'32''
> > Excellent idea! And thanks for the snappy response. This would
> > take the problem out of groff which would be a good thing for
> > this application (especially since the amount of creep required
> > =depends on the thickness of paper you are printing to, and I'm
> > much happier not to have
> However, this would not necessarily transfer to other fonts,
> since the \(f/ in standard PostScript occurs only in the
> Symbol font and so there is only one version of it. None the
> less, I have made the comparison in some standard Adobe font
> families (Times, Bookman, Palatino, Helvetica) a
> If anyone wants to reprint an email of mine to the wiki,
> that's fine with me.
Same here. I guess that's the whole point of this list.
> And it's only fitting that the wiki itself is written in awk.
Indeed. There used to be a *roff-(subset)-workalike called awf,
the "Amazingly Workable Fo
> > But this is a consequence of wrapping it in \{...\}, so if
> > you just remove the quotes from your argument it comes out
> > right.
No, this interpretation appears to be incorrect. The \{...\}
is at best ineffective here. You can see this if you define
the macro as follows:
.de temp
# arg
Just wanted to clarify a few things about environments. The
idea of environments is to define several different "parameter
sets" for formatting, with the purpose of being able to easily
switch between them (e.g., one environment for the normal body
text, one for footnotes, etc.), and to be able t
Ah, and I forgot to emphasize that one of the most
important aspects of environments is that the current
"partially collected line" is part of the environment.
Using environments, you can collect and format several
different "threads" in parallel.
__
> there must be an obvious answer to this question but I've looked and
> not seen an answer (yet). What is the best way to prepend commands to
> an existing macro. For example, say, in -ms how can one easily define
> a new `.LP' do some work and then call the original old `.LP' safely..
>
> Here i
> . If-else clauses look like this:
>
>.ie ... \{\
>...
>.\}
>.el \{\
>.\}
>
> Note the trailing backslashes! I think this was the reason of
> not getting more than a single footnote.
No, the reason for not getting more than one footnote was an
> 1) If small page size is set with -P-p2i,2i command-line
> switch for groff, pdf file produced by gs from
> the resulting eps file is not 2in x 2in, but full
> letter-size page (see foo_small.eps, foo_small.pdf,
> full_small.txt in the attached archive).
It usually *does* work
> Is anyone aware of a means by which floating point arithmetic
> and formating can be computed either within groff or in a
> preprocessor (ala eqn, tbl, etc.)?
Don't know whether this qualifies as "within groff", but you can
always call any of the various system utilities (and it has the
advanta
> Does any of the fonts in the standard distributions of groff
> contain characters depicting the standard male and female
> symbols? (The circle with the oblique arrow above, and the
> circle with the cross below.)
> Inquiring minds would like to know.
As far as I know, there aren't any in the
> 1. Resolution
[scanning in integer multiples of 72 dpi]
> Is this assumption right?
No. The basic axiom is that the *final* image to be printed is
at about device resolution -- let's make it a factor of two
better, just to be on the safe side. So, if your printer's
resolution is r, the final
How about this:
.de mysp
.nr myspcnr (v;\\$1)
..
.de myspcmac
.sp \\n[myspcnr]u
..
.blm myspcmac
and then just say
.mysp .4
if you want small spacing, or
.mysp 1
if you want larger spacing, etc.
___
Groff mailing list
Groff@gn
> Now the beauty of the thing is, that when you rotate a body,
> you rotate the normal vectors as well. When you translate
> or scale, you translate and scale the vertices, but not
> the normals. Now these "Whew!" guys transform the normals,
> always.
If you scale the body anisotropically, you
> > E.g. integer arithmetic etc is a relic from an age long
> > gone, it would be so nice to say good bye to it.
>
> Hmm. Nelson Beebe would raise a lot of objections. He
> regularly tests floating point packages and implementations
> whether they follow the IEEE standards, and there are still
> Perl has no integer arithmetic at all. I may sound scary
> 'cause it is much more oriented to computations than groff,
> but it works admirably. And nobody is up in arms that real
> numbers are in native machine format.
And let's not forget that other prodigious programming language,
employed
> Shrinkable horizontal space can probably be done without a complete
> redesign of groff, but vertical shrinkable space is impossible IMHO.
Vertical shrinkable (or rather, stretchable) space can be done
easily with macros and a diversion. (I assume the purpose of
this is for alignment of the bo
> > > Shrinkable horizontal space can probably be done without a
> > > complete redesign of groff, but vertical shrinkable space
> > > is impossible IMHO.
> >
> > Vertical shrinkable (or rather, stretchable) space can be
> > done easily with macros and a diversion.
>
> Well, yes, but using divers
> > > > Vertical shrinkable (or rather, stretchable) space can
> > > > be done easily with macros and a diversion.
> > >
> > > Well, yes, but using diversion has a lot of side
> > > effects...
> >
> > What do you mean by "side effects"?
>
> Mainly that data put into a diversion can't be complet
> You could of course define a macro/parametrised string on the
> lines of
>
> .de eval
> .nr Neval \\$*
> \\n[Neval]
> ..
>
> The value of \en%+1 is
> .eval \n%+1
> (correct since this is page 1).
>
> which produces the output
>
> The value of \n%+1 is 2 (correct since this is page 1).
Unfortu
> > I believe TeX uses a similar concept (i.e., storing
> > ready-formatted text), only they call it "boxes", not
> > "diversions", and TeX has an optimizer to decide where to
> > pagebreak, not just a simple vertical-position trap.
>
> Well, in TeX I can always `\unhbox' or `\unvbox' a box
> to
> . nr env-count 0 1
> .
> . de CI
> .ev e-\\n+[env-count]
> .nop \&\\$*
> .nr have-int \\n[.int]
> .ev
> .fam C
> .ie \\n[have-int] \{\
> . I \&\\$*
> . fam
> .\}
> .el \
> . I \&\\$*\F[]
> ..
This seems to screw up for very long arguments. I gues
> Excellent! This is *very* nice.
Ah, well, long time ago I had the same problem with the
large spaces after text set in Courier, and that's how I
solved it. (I use font positions instead of families,
but the behavior is essentially the same.)
One feature the macro doesn't implement is that
in
> Attached is a reduced version of groff.texinfo,
> together with a PDF version of it.
Incidentally, looking at the PDF file, I wonder what could
possibly be the purpose of using "italic" dots as leaders
in the table of contents?
___
Groff mailing l
The following works:
.\" tbl
.eo
.de ATABLE ..
.TS
allbox tab(;);
cl.
\$1;\$2
.TE
...
.ec
.ATABLE A table
.ATABLE Another table
.ATABLE And "another one"
___
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
> this is interesting. At the moment I am in the need of exactly
> the same thing. So this comes in handy. However I want to have
> a variable parameter list. At maximum I can have up to 10
> parameters. Each parameter opens a new row. If the Parameter
> is empty the do not open a new row.
> The
[snip]
That was supposed to have been "... simply isn't there in
_the_ macro that we use ..." (I shouldn't try to explain
things in a hurry.) Anyhow, here's a little example to
illustrate further the behavior of tbl/troff:
.\" tbl
.de HR
.br
\v'-.25m'\D'l \\n(.lu 0'
..
.sp 3c
.ll 7.5c
.HR
.ce
> I want to have a variable parameter list. At maximum I can
> have up to 10 parameters. Each parameter opens a new row.
> If the parameter is empty then do not open a new row.
If you can restrict yourself to a simple, particular layout and
don't need the full flexibility of a general table form
> I'm using refer to print out an annotated bibliography, and
> would like for the annotation paragraph to contain troff
> commands for paragraph breaks, and maybe even pic diagrams or
> code fragments. However, refer turns the annotation text into
> one long string defined using the .ds command
> Well, it is justifiable, but it isn't documented correctly.
The only justification I can think of is that this way it is
not apparent when a closed curve isn't closed properly (in the
Postscript sense). This shouldn't happen in a Postscript-aware
application, however.
> What exactly do you wa
It works if you use ".ig xx" paired with ".xx" (substitute some
reasonable name for xx if you like; make sure its defined as a
no-op).
Explanation: this is like nested definitions,
.de xx
.de yy
hello
\\..
..
where you have to "hide" the inner terminating "..", so that
when defining x
> Unfortunately this one looks for `%!' and does not copy lines starting
> with these two characters.
> Since you can not exclude the possibility of such a combination,
> ascii85 encoded files are out.
You can turn this off. See the description of "broken"
in the manpage of grops.
> > > Well, it is justifiable, but it isn't documented correctly.
> >
> > The only justification I can think of is that this way it is
> > not apparent when a closed curve isn't closed properly (in the
> > Postscript sense). This shouldn't happen in a Postscript-aware
> > application, however.
>
> Please convert the information in your email into a patch for
> grops.man, together with the example.
Done (more or less). I've also taken the liberty to restructure
the grops manpage somewhat, i.e., begin the "Usage" section with
the discussion of the general workings of grops instead of how
> If anyone can think of a context where a hyphen break between
> two numbers is OK, I'd be very interested to hear of it!
> And, if the exceptions are so special, then I'm sure that
> Werner's workround of "\:" should be acceptable, since people
> are not going to need it all that often.
> Meanwh
> BTW, in German, AFAIK, you should use `-', not \[en].
Are you sure about this? I just checked a few examples
(real books, so I assume these were created by professional
typesetters) both old (letterpress stuff, yay!) and new, and
they all use the en dash (or, in an old book, something longer,
> I have sometimes (slightly mad idea ... ) considered (at
> least experimentally) re-writing relevant macros such as
> ".PS/.PE", ".TS/.TE", ".EQ/.EN" so that they automatically
> write out what occurs between the start and end to a file,
> run the appropriate "preprocessor" program on the file,
> > (it just would be nice if the `.so' request _could_
> > interpolate the string register value)
>
> Indeed, but I don't see how to do that properly.
It *does* interpolate the string register value, but only
at *troff* runtime. (Well, actually it's not the ".so"
request that does the interpol
> Is this a bug or a well-considered feature?
Apparently groff treats a space differently from "real" characters
(like in TeX, where a space in the input represents glue in the
output, not a printable character).
> Is there a way to save this structure?
Yes. Do a ".tr ~" before, and then use ~
> Not really. With -Tascii you get
>
> warning: can't find numbered character 32
It seems the reason this worked for me is that I had edited the
font description files to include the space as well. Are there
any situations where this could produce undesirable results?
> It's a bug in grops
> > (b) it works with old troff also (which has a limit
> > of 9 macro arguments)
> >
> Actually the limit was 6 macro arguments for man macros
> in the 1980s.
Old troff had a general limit of 9 macro arguments. The
limit of 6 arguments you're referring to came about because
the particul
> > I suspect the .SCRIPT-INPUT-BEGIN .SCRIPT-INPUT-END could
> > be implemented as macros which map onto a similar escape
> > technique as the suppression escapes \O etc. In any event
> > the obvious advantage to this approach is that one can
> > harness the ability of a scripting language to m
> you've replaced `cdot' with \(md in eqn -- why not replacing
> `...' with three \(md characters too?
Don't! I want to have the "normal" ellipsis on the baseline.
(Like in 1, 2, ...; for special cases it's preferable to have
a separate "cdots" operator with three \(md characters.)
> I'd like to have all eqn terms appear in a single colour.
> gfont chooses the eqn font, but there appears no easy way
> to have all eqn terms appear in a specific colour. Any
> suggestions?
Well, it's kinda possible (see attached PDF), but it involves
some terrible hackery. I guess it would b
> There was no response from the list. I don't want this change
> to hang forever waiting for one if nobody cares about the
> issue.
I prefer the version with the punctuation on the ending macro only.
> Actually, your suggestion is very nice IMHO.
It's dependent on too many assumptions. And the colors
are assigned only on basis of the font used, not on the
semantics of the formula. [Not that we would really need
this all of a sudden. In most of history, mathematicians
have been able to make
I'm not familiar with DocBook, but doesn't it have something
analogous to HTML's "definition list"? It occurs to me
that some of the "tables" you're discussing might be better
served with such a definition list (as is actually currently
the case).
Not every two-column table is a definition list,
> I would expect the word "footer" to pop up at -2c from the page bottom,
> then a page break. Footer does pop up, and there's the page break too,
> however it does not show up at -2c from the bottom. It's lower.
It is working as intended. When you say ".sp |0c" in troff,
that does not mean tha
> How should I proceed to achieve precise margin sizes?
There's two things to consider here. One: the trap is sprung
when a line is output that reaches OR SWEEPS PAST the trap
position. If you set your trap at -2 cm, then an output
line may nevertheless still intrude into the bottom margin
of 2
> A slight change and you can colour the margins with pure troff
> so it works for both postscript and pdf:-
Very good! Your example also demonstrates how setting the
vertical spacing to zero allows directly positioning the baseline
(which is the reference position for "\D" drawing commands)
wi
> Rare? Maybe. But not so rare that a macro package need not
> be prepared for it.
I think leaders are meant to be used in conjunction with
diversions. When they are used in already formatted text,
all required dimensions are known, allowing n/troff to
compute the number of leader character re
> The example was enormously helpful. There's light at the end
> of my TOC multi-line entry tunnel.
Happy to be of help! Note that the example was simplified to
illustrate the principle, and would need some (minor) aesthetic
tweaks for practical application. Most importantly, you will
want the
> If you put a bar over a string of As, the length of the bar increases
> by the same amount for every A you add, but that amount is not the
> length of a bar over a lone A.
> This nonuniformity is unfortunate.
This appears to be by design. The manual page says:
accent_widthWhen bar or
> Can we create documents that have chapters, sections,
> that are in separate files? How can we do this?
Use the method you already described that works: source the files
directly from the main document, not from within a macro.
> Now if I run this main file using
> (cat main.tr | groff -p -
> > So because both being above ASCII (8 bit area),
> ASCII is not an 8-bit code. It is a 7-bit code, [...]
Latin-1 is a superset of ASCII, with ASCII occupying the lower
half, so technically I would argue that the above statement
"being above ASCII" (namely, being in the area where the
eighth
> AT&T troff was engineered around the assumption that the
> lowercase Greek letters typically used for mathematical and
> scientific typesetting are slanted/italic rather than upright.
> This assumption is baked into the semantics of special
> character names *a, *b, *g, and so forth.
> [...]
>
[Redirected to the list, since I believe it is of general interest.]
> > Which character (slanted or upright) groff uses simply depends
> > on the mounting order of the fonts S and SS.
> >
> > [...]
> I never knew this. Where is the reference please?
> I would like to mention this in my new
> Note that there is no SS for 'devpdf'. So, from where does
> -Tpdf find (or construct) the slanted versions of the Greek
> letters if the standard symbol font has upright Greek letters?
> Or are the two 'S' fonts different for -Tpdf and -Tps?
In the current groff release, the slanted Greek cha
> The ordering of the S and SS fonts is immaterial here because
> the C/A/T _had_ no SS font.
> Nor do I see any of evidence of an "SS" font for _any_ device
> in Documenter's Workbench 3.3 troff.
> Barring evidence of pre-groff usage, then, I submit that the
> slanted symbol font must be a groff
> For people producing greek documents who wish to use eqn,
> I did some testing, using the Tinos family of fonts (R, I,
> B, BI) which include greek glyphs and SS font for gropdf.
> The attached pdf shows the results with the different
> fonts colour coded.
Nice! How did you do the color coding
> > \fB\s(12\m[red]\X'ps: big bold red text in my device command'\fP
> \X'ps: exec 1.0 0 0 setrgbcolor /Times-Bold findfont \n[.s] scalefont setfont
> (Text) show'
This assumes you know both the desired font and the desired
color, which might be defined at other places in the document
and not u
> Processed with
> pdfmom -Kutf8 -k timeline.mom > timeline.pdf
> the é is garbage.
If I swap the order of the options:
pdfmom -k -Kutf8 timeline.mom >timeline.pdf
or leave out the "-k" entirely (since it is implied by "-K"):
pdfmom -Kutf8 timeline.mom >timeline.pdf
it works on my mac
> However, pdfmom is supposed to accept all the same
> options as groff. Here, it does not, since "-Kutf8 -k" is
> acceptable to groff.
>
> groff -Tpdf -Kutf8 -k -mom timeline.mom > timeline.pdf
>
> works but
>
> pdfmom -Kutf8 -k timeline.mom > timeline.pdf
>
> fails.
In the perl script
> (I use a bitmap font because it's substantially more readable
> for long periods of time than any TrueType font I've found at
> equivalent sizes, but using a bitmap font disables some of
> xterm's font family support.)
The xterm source can be hacked to provide italics using the
classic bitmap f
> Predict the output of the following *roff input.
> [...]
I guessed wrong. And Heirloom nroff behaves differently
from groff. Some more unexpected behavior can be seen
by shortening the line length to just 1 en.
I also tried the same thing in TeX and learned that by
default TeX doesn't hyphe
> > Also interesting to see that in this word, the hyphenation
> > patterns don't suggest a hyphenation opportunity after "anti".
> The leading `\%` prevents that.
Sorry, I meant even without "\%". With a line length of 1 en,
and without any "\%" at all, groff prints
an-
tidis-
es-
t
> I prefer groff's behaviour because I don't ever want correct
> hyphenation points to be ignored. Using \% is almost always a
> correction to the hyphenation logic.
Groff's current behavior is weirdly inconsistent.
It already *does* ignore correct hyphenation points,
namely before the first "\%
> Groff already *does* ignore correct hyphenation points,
> namely before the first "\%" (but allows them afterward).
>
> My concern is that if "\%" only allows specifying
> *additional* hyphenation points, then we have no method
> of forbidding hyphenation points that the patterns
> incorrectly
> $ printf '.ll 8n\n\\%%antidisestablishmen\\%%tarianism\\%%\n' \
> | nroff -Wbreak | cat -s
> antidisestablishmen-
> tarianism-
>
> I don't think we can tolerate that trailing hyphen.
Yes, that's why we have to use "\&\%" at the end.
> Which would be better?
>
> 1. Change GNU troff to not write out a hyphen if the
> hyphenation control escape sequence is at the end
> of the word.
>
> 2. Change GNU troff to not reënable automatic
> hyphenation after encountering a non-initial
> hyphenation control escape se
> More precisely, you get the Death Star, not the Wehrmacht helmet.
> The latter is what appears in 32vscan.pdf.
> > Be nice to include that.
Wikipedia has an SVG of the logo, but it's a bit asymmetric.
Instead of trying to fix it I decided to draw a new one,
based on a bitmap image I found on
> [2] Maybe introducing a replacement term, "rotated"--which is
> unused in the GNU pic manual except to define "aligned"--would
> be a good idea [...]
I don't think this is a good idea. "aligned" in pic means
the direction of the text is aligned with the direction of
the object:
.PS
arro
[Spoilers ahead.]
> A Question: is the `vs` request (which sets the vertical spacing)
> honored in nroff mode?
Yes.
> B. In nroff (or nroff mode in groff), what _units_ is the argument
> to the `vs` request reckoned in?
I remember .vs always being given in points, with a default v
> some of the huge tables which in my original sources spread
> over two book pages, appear truncated by the PDF, no matter
> what papersize I try to set (e.g. like A3).
The default column separation is 3 ens. We can make the table
a bit narrower by reducing this to 2 ens,
lb2 s2 s2 s2 s2 s2
> > a "margin" measures an extent of whitespace (or "negative space"),
> > whereas the `sp` request positions the _text baseline_,
The first is correct and the second incorrect for [g]troff.
In troff (and nroff), if you say
.sp |0
then this does not mean "put the baseline at the top of the pa
> I will defend my formulation. `sp` _does_ position the
> text baseline, period.
I concur. It positions every part of the line.
I simply did not want anyone to get the impression that
".sp |3c" would put the _baseline_ at 3 cm from the top.
Also, in this case the baseline will only _normall
> For a small fanzine project I want to typeset magazine
> style end marks [1]. Particularly I want to include the
> authors handle or name in the end mark, like seen for
> instance in some articles like in this issue of the
> Space Gamer Magazine [2].
How about this (see attachment)?
It prints
I suspect conventions might be strongly regionally
dependent.
> - Em-dashes are represented by two hyphens with no space
> either side--visually easy to understand.
>
> - En-dashes are represented by a single hyphen
> surrounded by spaces (e.g. 2 - 3 minutes).
I believe this should be rever
> .hlm nSet the consecutive automatically hyphenated line limit
>to to n. A negative value means "no limit".
What happens after that count is reached is that the next
line is stretched wide, simply to avoid hyphenation (unless
.na is used, in which case the line is simply broke
> \s[-X]\H[+X]text to be kerned goes here\H[0]\s0
I believe distorting the shapes of letters is even more frowned
upon in typesetting circles than consecutive hyphenation is.
As a practical approach to manually optimizing the line
breaks in a paragraph, I have found that twiddling the space
siz
> > I believe distorting the shapes of letters is even more frowned
> > upon in typesetting circles than consecutive hyphenation is.
>
> Tadziu, were you referring to your language (where I *think*
> hyphenation would always be necessary)?
Sorry if my wording was a bit vague. I was referring t
> How does the formatter know which parts to fill?
In the case of groff (I can't say anything about the original
troff), I don't think the formatter actually knows or cares,
but simply passes the path on to the device postprocessor,
which just incorporates it into the device-dependent output,
to
1 - 100 of 694 matches
Mail list logo
