Re: [Groff] Sun's troff now available

[Ted Harding]

On 25-Jun-06 Peter Schaffter wrote:
> 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.

Also very useful is one (say) interpolates Courier font with Times
Roman (as for example when referring to program names), since the
usual fonts for CR and TR don't nicely match visually in size.

>>   .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.

This triggers an issue which I've been thinking about for a while
without managing to get a proper handle on it in the code.

A number of issues (and the one raised by Peter is an example) in
groff formatting could be solved provided, once an output line has
been fully formatted and is about to be output, one could then
access that object and perform some final tweaks to it before it is
actually sent out. At present, this last stage takes place within
a black hole in groff, and the user cannot intervene.

The example which first prompted me to think about it was the
problem of continuous underlining (since then nicely solved by
Werner by other means). There is no particular difficulty in
drawing an underline from the left margin to the right margin
for a line which needs underlining in its entirety; but when
the underlining starts in the middle of one line, and ends in
the middle of another, then one needs to know the position in
the output line of the character where it starts or ends. This
is implicitly stored in the finally-formatted output-line object.


> [Peter's fascinating tour of the Typesetting Museum snipped]
> 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.

I have to agree with this. Whenever I have wanted to produce
fine-tuned output, I wait until I'm sure the document is in
final form. I then go back to the troff source, and re-format
this text file so that there are line breaks in the troff source
where there are also line breaks in the printed output. At this
stage, of course, this re-fromatting has no effect on the layout
of the printed output.

Then you can interpolate troff requests/macros to make the
adjustments you want, on a line-by-line basis, where needed.

Indeed, prior to Werner's underining macro, this is how I used
to deal with the continuous underining issue. And you can also
deal with the "hanging characters" problem in this way too.

Once again, I suspect that all this kind of thing could be
helped by pre-output access to the finally formatted output
line (since the mechanism I describe above amounts to this,
but riding a mule to climb the mountain rather than taking the
helicopter).

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 26-Jun-06                                       Time: 10:34:03
------------------------------ XFMail ------------------------------