Deri James writes: >I have, so far, kept silent on future direction for groff, since my >own use for groff is probably very rare, so my opinion should not >carry much weight. I use groff as a typesetting engine called from a >front end which produces a troff file which is then passed to groff to >produce output. The troff file uses just the basic troff commands, no >macro calls. For this reason I am only interested in the presentation >side of the argument. > >I completely agree with the separation of style content and logic, but >I do this in the front end rather than in the troff file.
I may as well add my voice too. I use groff on a daily basis, although whether you choose to assign any extra weight to that fact is up to you. I too use groff as a typesetting back end. I have a front end which generates a groff/tbl input file, which is then typeset and turned into a PDF which is sent out to customers (or sometimes printed and physically sent out, depending on the customer). I firmly believe that groff doesn't necessarily need to change to stay relevant (arguably, it hasn't been relevant to the majority for some time anyway). Yes, separation of presentation from content is important. But does it need to be done within groff? I'm not so sure. You risk turning groff into something else entirely. At which point, why not just leave groff as is, and write the something else as a separate program? Potentially one that outputs groff input files if necessary, and HTML/whatever as an alternative for those that want such things. Tet
