On 21-Feb-06 Miklos Somogyi wrote: > [...] > I only have one philosophical question-mark. When I was a > youngster (yes!), device independence and pre- and > post-processors were good ideas and necessary. > I wonder whether it still is the case. > We, who got used to them, are comfortable with them. > I'm not so sure about today's youngsters. > Probably they would say that the dust has settled, Adobe won > (whether they like this or not), so why concentrate on > anything else than ps and pdf. > And perhaps they would like a single application better, > a groff with built-in tbl, eqn, me or mm etc, producing, > say, only ps. I don't know, but sometimes it pays if one > questions his/her whole approach As Time Goes By.
Interesting questions, and I have thought about them myself from time to time. On balance, I think the existing structure (pre- tbl, eqn, pic etc.; post-devps etc.) works well in most cases and gives flexibility. There are certainly cases where one needs to call one or more of the pre-processors in the "troff" phase of the pipeline, and even interpose a "pre-post-processor between the ditroff output of troff and the final post-processor. Regarding in-line tbl, eqn, pic: This is needed when the operation of the pre-processor depends on something which can only be evaluated during the troff phase. Examples include: a) Computing the width of a box containing text in a 'pic' block. This can only be done using both the text itself and information about the font, the point-size, and the font metrics (e.g. with the "\w'text'" sequence), and the font and its metrics are unknown until troff looks at it; and the text itself may be dynamically generated during the troff phase. b) Computing the values of numerical coefficients in an equation expressed in 'eqn' language, where these may depend on what is in some data file accessed by troff using ".so datafile"; also, the general numerical engine in groff is in 'pic' so as well as in-line 'eqn' you may need in-line 'pic' as well. c) Similarly for 'tbl. It is certainly possible to achieve (a), (b) and (c) by using troff requests to write out lines to a temporary file or files, use the ".sy" request to run 'tbl' or 'pic' or 'eqn' on these saving the results to other temporary files, and then using ".so" to read these results back in. It can get quite complicated to set this up in some cases, and it may be worth while encapsulating the procedure in macros. This may look simple on the surface -- e.g. (in outline) .de pic [open diversion] .. .de /pic [open temp file1] [emit ".PS" to file1] [write diversion to file1] [emit ".PE" to file1] [run pic on file1 writing to file2] .so file2 .. and then, in-line: .pic [pic code using variables already defined] ./pic -- but in practice one can find that it is not straightforward; and it can be even less straightforward if you need to include a call to ".pic" within a call to ".eqn", say. However, I still think that such an approach is probably better than embedding the functionality of the pre-processors within the troff binary. Nevertheless, I have to admit that this attitude may well be a consequence of "youthful" experiences a long time ago, when (as indeed now) this was the only way to do that sort of thing, and once you have taken the trouble to work out how to do it you develop a commitment. Best wishes to all, Ted. [Leaning on his wooden ploughshare] -------------------------------------------------------------------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 22-Feb-06 Time: 10:10:32 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list [email protected] http://lists.gnu.org/mailman/listinfo/groff
