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
