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) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Jun-06 Time: 10:34:03 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff