On 26-Jun-06 Peter Schaffter wrote: > On Mon, Jun 26, 2006, Ted Harding wrote: > [...] >> 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). > > Good analogy. > > FWIW, back in the Museum, even though galleys were set from > what amounted to "source files", the workstations had a > continuously updating "status line" that told you exactly where > you were, both vertically on the galley and horizontally on the > currently-being-input line (measured from the position of the cursor > in the input text). By keeping an eye on the status line, you could > make a lot of judgment calls concerning where to break troublesome > lines, how much kerning to apply, etc. during the first run. > > I'm wondering if this is the kind of "pre-output access" you're > envisaging. Hard to imagine how groff could implement it in > user-space, nice though it would be. Seems to me it would require a > specialized front end.
Sort of, I think -- though it looks as thought you're seeing the status line prior to, or while, the output is still being formatted. The sort of thing I have in mind is targeted right at the line which is about to be output, as follows lines. Suppose you have formatted output lines (say, as you mentioned, in a narrow-column context) like: This formatted line needs smaller spaces. So track kern- ing can be used to reduce them. If you had a "pre-output" macro (just as you can have macros which are sprung by bottom-of-page, so you could have macros sprung by "about to output line"), then this could look at a) Inter-word spaces: if larger than a threshold, expand the inter-character space until these are reduced below it. b) Is there an end-of-line character (like the soft hyphen above, which might not have been explicit in the source) which we would like to hang over the end of the line? Then slightly increase the linelength of this line (or redefine "-" to have smaller width, or whatever) so that it sticks out by the right amount. c) Similar for "\(lq" at the start of an output line or "\(rq" at the end, hanging punctuation, etc. ... The end result would probably be acceptable in most cases, and would have been created automatically, so there's no need for extra work during the draft phase. Once the document is in final form, you can then read it through and, for those relatively few cases where it still needs adjustment, use the bare-hands methods we've been describing. However, if all has gone well (which depends on well-tuned design of the "output-line" macro), the extra work involved in this would be a small fraction of the work to do it all by hand. Best wishes, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 26-Jun-06 Time: 19:06:14 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff