I have just seen that these comments, which have been gestating for some time, are somewhat outdated by the appearance of mission statement 3. Still I think they may be of some use.
Mission statement 2 begins with a precis of what groff is, but no | overt expression of the purpose of the groff project, as I would | expect of a mission statement. I think this lack should be rectified. | The rest of the document is a to-do list, expressed in terms of | "frontend" and "backend", which apparently mean macro package, | and groff proper. Things even further front (eqn, etc) or back | (grops, etc) are not mentioned, though surely they are in the | project's purview. I'm skeptical of Knuthian line-breaking, which heads the to-do list. I have been frustrated too often by trying to outwit AI in Word I have just seen that these comments, which have been gestating for some time, are somewhat outdated by the appearance of mission statement 3. Still I think they may be of some use. Mission statement 2 begins with a precis of what groff is, but no | overt expression of the purpose of the groff project, as I would | expect of a mission statement. I think this lack should be rectified. | The rest of the document is a to-do list, expressed in terms of | "frontend" and "backend", which apparently mean macro package, | and groff proper. Things even further front (eqn, etc) or back | (grops, etc) are not mentioned, though surely they are in the | project's purview. I'm skeptical of Knuthian line-breaking, which heads the to-do list. I have been frustrated too often by trying to outwit AI in Word and fmt. Pseudo-Knuthian line-breaking in the latter is a bloody pain. This email was formatted with fmt. A glance at the previous paragraphs, where the line length is marked, shows the capricious result. Some paragraphs below are even more astonishing. As for real Knuthian line-breaking: when forced to use TeX, I typically resort to "/sloppy" mode to avoid the temper tantrums TeX throws when it can't do a good job. But my fundamental complaint about Knuthian line-breaking is that anything that takes 66 journal pages to describe can't be right. It is out of keeping with the Unix ethos of simplicity and generality--and with the "small size" of groff that the mission statement praises. There is one property of TeX (and HTML) that's worth emulating: recursive nesting. It's a challenge to the preprocessor model (eqn, tbl, pic), but one that deserves serious consideration. How about letting "preprocessors" be called by piping segments out and back, not only by piping in? (This is a standard facility of the sam editor. The line breaks in this email were set by piping out to fmt.) Another issue worthy of hard thought is the handling of cross-references, and the creation of parallel interconnected galleys, e.g. table of contents and bibliography, to be collected--perhaps after certain massaging--into a single document. These things are handled by a collection of special purpose tricks in both TeX and groff. Is there a general pattern that can be supported here? I have to agree that making it easy to incorporate new typefaces from disparate sources is an important task, nasty as it may be. As for frontends, I would like to see some modularization of macro packages. The fact that mom is as big as classic troff itself should give one pause. To what degree is it possible to separate various style-sheet issues into orthogonal subsets that can be reused? Some potential modules might be: text style (paragraphing, fonts, etc) document descriptors (title, author, etc), page matters (head, foot, columns), section structure (may invoke different body-text styles) etc. Is any enabling architectural change in groff proper needed to support this? (Notice that the topic is not unrelated to recursive nesting.) I agree that good candidates for updating the man macros are likely to be found among the readership of this mailing list. However, the biggest problem with man pages is that people don't write them. groff_mom(7) is a recent example--all it does is point somewhere else. The biggest culprit is info--a maddeningly archaic facility to which Gnu clings tenaciously. Unless it can be foreseen how new man macros would displace texinfo from its throne, the exercise will largely be in vain. [Full disclosure. Having edited the 7th to 10th research-edition manuals, I am very partial to man pages, though I have no special affinity for the man macros.] While a to-do list is on the table, is there anything that needs to be done for eqn, tbl, pic, and other preprocessors? I think eqn's syntax largely improves on its successors', to borrow a phrase from Tony Hoare. I only see a few minor annoyances. One would like to be able to describe matrices by rows as well as by columns, and a snappier notation for subscripts and superscripts a la TeX would be convenient. Incidentally, I do not think TeX's math spacing by operator precedence is much preferable to eqn; it's hard (or impossible) to undo when it's inappropriate. Tbl is a bigger deal, because nesting comes to the fore. I sweated a while back to make a table that contained pic diagrams, images, and equations, as well as plain text. The grail remains to be found. In pic, the thing I miss most is polygons (preferably allowing arcs and splines as edges) that can be filled. After that, the next step is a big one: lightweight constraint-based drawing; Van Wyk's Ideal (SIGPLAN Notices 16:6) is a proof of concept. Can that be gracefully folded into the current pic model? Of all the preprocessors, Refer is probably the weakest. One of the "parallel galleys" mentioned above, it may profit from some architectural support. It certainly needs style sheets--another aspect of frontend modularity. I would suggest, too, that the set of categories (author, date, etc) be modest, but extensible. Bibtex's "exhaustive" list is overkill, I think. Speaking of macros, is there any hope of reconciling the macro schemes of groff, pic, and eqn? Or is it obviously silly to try? Finally, I repeat that the mission statement should offer a guiding purpose as well as a to-do list. Doug
