[Top][All Lists]

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

Re: [groff] Macros in their own package ...

From: Larry Kollar
Subject: Re: [groff] Macros in their own package ...
Date: Sun, 25 Feb 2018 00:19:40 -0500

> John Gardner <address@hidden> wrote:
> Apropos of compatibility outside `groff`...
> Does anybody know of an exhaustive list of *roff implementations still in
> common use? (Including legacy repositories of historical interest)
> The current Roff interpreters I'm aware of are:
>   1. *GNU Troff <>* (~1989/1990 ‒
>   present)
>   2. mandoc <> *[1]* (2008 ‒ present)
>   3. *Heirloom Doctools <>*
>    (? ‒ present)
>   4. *DWB 3.3 <>* (???? ‒ 1993ish)
>   5. *Solaris 10 ditroff <>*
>    (1980s ‒ ?)
>   6. *Plan9 Troff <> *(???? ‒
>   present)
>   7. 9front Troff <> (???? ‒ ????)
>   8. Utroff <> (Which I know nothing about)

You’re missing neatroff —

I think both Neatroff and Heirloom are based on Plan9, FWIW.

I think Groff is unique in providing an HTML post processor, however ham-fisted
its output might be. It depends mightily on macro packages feeding it hints to
get the elements correct (especially lists). So, in Groff,  both -ms and -man 
have a
bunch of extensions that support -Thtml.

In my mind, the *real* question is, what’s our vision for the *roff family? Not 
Groff, but all the others in the list above (plus any we’ve forgotten about 
That, IMO, is driving the “split vs. monolithic” divide here. I see three 
visions in play:

        Source is *roff, and there isn’t much interest in moving things in or 
out. It would
        be nice to interchange between different formatters, with (at most) 
minimal fixes.
        But there’s little or no interest in working with the rest fo the 
world. I kind of see
        most of the “don’t break out the macro packages” folks in this category.

        *roff becomes an intermediate step from some other markup language 
        an XML variant) on the way to PDF… or maybe manpages. In other words,
        documents check in, but they don’t check out. Frankly, I’ve moved here 
        Walled Garden in the last couple of years. Those of us in this category 
are interested
        in portable macro packages so we can shift to a different formatter if 
it better meets
        our requirements.

        This is where I’d *like* to be. There are been attempts (doclifter and 
-Thtml being
        two of the most ambitious) to make *roff output interchangeable with 
the rest of 
        the world, but they fall short. Portable macro packages are the easy 
part, in this
        scenario. Still, I think there’s value in the attempt(s) to make *roff 
easier to
        interchange with the rest of the world. Markdown is eating our lunch in 
this category;
        you can take its squeaky-clean HTML output and transform it into 

Given the continued development of all *roff variants, it’s obvious we have 
to offer the rest of the world. We just need to figure out what that is.


reply via email to

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