groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] The future redux


From: Tethys
Subject: Re: [Groff] The future redux
Date: Fri, 28 Feb 2014 00:28:09 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]