Re: [Groff] Sun's troff now available

[Peter Schaffter]

On Sun, Jun 25, 2006, Werner LEMBERG wrote:
>   .fzoom
> 
>      Apply a scaling factor to a font.  Useful to harmonize the size
>      of different fonts like Times and Helvetica if simultaneously.

Brilliant.
 
>   .minss
> 
>      Minimum word space when adjusting lines.  I consider this a quite
>      elegant solution to circumvent the problem of not having
>      shrinkable whitespace in groff.

This one would be a good start, but it's not enough for top-quality
typesetting.  I've written on this before.  Groff needs a
line-adjusting mechanism that takes both word- and letter-spacing
into account.  Ideally, the two would be both stretchable and
shrinkable, although shrinkable appears to be out of the question.

Throughout the 80s and early 90s, I worked on a number of different
phototypesetting machines (Quadriteks, Compugraphics, Linotronics,
etc).  These guys all had their own proprietary operating systems,
which were designed for one task only: to set type.  None were
sufficiently sophisticated to have anything resembling TeX's
paragraph formatting algorithm.  Instead, they worked much as groff
does, i.e. on a line-by-line basis.  However, their manner of
adjusting/filling individual lines produced a much better "grey"
than groff.

Basically, these systems all had settable word- and letter-spacing
options, with defaults built in.  Both the word-spacing and the
letter-spacing were divided into three parts: a minimum space, an ideal
space, and a maximum space.  I never saw the source code for these
systems (no one did!), however the behaviour they exhibited was:

1.  Gathered letters and wordspaces at their ideal spacing until a
    critical zone was reached (typically a few points either side
    of the left margin: left of the left margin--a short line--was
    "positive"; right of the left margin--an overlong line--was
    "negative").

2.  Determined whether reducing the letter-spacing incrementally
    down to its minimum, or expanding the letter-spacing
    incrementally up to its maximum brought the line to a break
    point (i.e. a word-break or a legal hyphenation point).  If
    letter-spacing adjustments by themselves could not bring the
    line to a break point, selected which letter-spacing adjustment
    brought the line closest to a break point within the critical
    zone (positive or negative).

3.  Determined whether, with the letter-spacing selected by 2,
    a break point could be achieved by reducing or expanding the
    word-spacing.

4.  If 2 and 3 couldn't achieve a break point, used the first value
    from 2 that fell within the critical zone's positive side
    (i.e. a "short" line) and stretched the word-spacing without
    restriction until a break point was reached.

It doesn't sound terribly sophisticated, yet it worked well enough
to satisfy even the most demanding designers and proofreaders.  I
wonder why, even working within groff's limitations, a similar
(though obviously not identical) line-adjusting procedure isn't
used.  At present, groff's line adjusting mechanism requires a
huge amount of manual intervention to achieve what was being done
automatically on rickety old Quadriteks three decades ago.

>   .lhang/.rhang
> 
>      Hanging characters at the left and right margin, respectively.

This would be wonderful.

-- 
Peter Schaffter