Re: [Groff] space width

[Peter Schaffter]

On Mon, Jan 27, 2014, Tadziu Hoffmann wrote:
> If I may hazard a guess, it is possible that the notion of
> *doubling* the space did indeed come from typewriters, where
> spaces came in one size only.

This is almost certainly the case.  And one does wish that writers
of text destined to be read at the terminal would observe the
double-space convention since it significantly enhances readability.

> In lead typesetting there were spaces of many different widths,
> and the typesetter probably did not insert two "normal" spaces,
> but simply a larger space (e.g., a quad).

In typsetting, it's easy to get lost in trying to figure out which
conventions to follow, when, in the end, good judgment should prevail.
Judicious use of the second arg to .ss makes text easier to follow,
especially in long paragraphs.  That alone is sufficient reason
to dispense with slavishly following current or past wisdom.

In mom, sentence spacing is provided by .SS, and despite the advice
in the docs, I use it in almost all my work.  The amount of sentence
spacing need not be very much.  In fact, it should be scarcely
noticeable, just enough to improve paragraph rhythm.

As for track kerning, that's provided in mom via .RW (reduce
whitespace) and .EW (expand whitespace), and frankly, in the absence
of a paragraph formatting algorithm, I find it indispensable.  All
sorts of paragraph problems--lines with too much word space, awkward
hyphenation, widows and orphans--are easily fixed by applying a
small amount of RW or EW to entire paragraphs, usually as little
as <0.5.

As for the "rightmost glyph" issue, I have to say that I've never
noticed it when using RW and EW to fix paragraphs.  If you look at
the mom source for _Producing PDFs with groff and mom_, you'll
see that a number of paragraphs use track kerning yet the output
shows no noticeable change at the right margin.

As for line/paragraph formatting algorithms...

Back in the day of standalone phototypesetters, eg. the mighty
Linotronic or CompuGraphic's 8400, everything was line-at-a-time
yet the results were almost always better than what can be achieved
with groff.  The reason was that both word- and letter-spacing
(track kerning) were used to auto-justify lines.  For each,
min-opt-max values could be given, which would then be used to
determine optimal breakpoints with the best overall grey to the
line.  When I first came to (g)troff, I was actually quite suprised
by its lack of sophication when it came to justification.

I'm wondering if that older approach wouldn't be the better way to
go if, one day, groff gets an overhaul in this area.  I don't know
the internals, but I'm thinking it might be easier to implement,
since it's still line-at-a-time.

-- 
Peter Schaffter
http://www.schaffter.ca