[Top][All Lists]

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

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

From: John Gardner
Subject: Re: [groff] Macros in their own package ...
Date: Sun, 25 Feb 2018 17:16:43 +1100

> There are been attempts (doclifter and -Thtml being two of the most
ambitious) to make *roff output interchangeable with the rest of the world

I have something planned. But it's so ruthlessly absurd nobody would take
it seriously without proof. =) Hence why I'm not speaking up about it until
it's finished.

> you can take [Markdown's] squeaky-clean HTML output and transform it into

Markdown's output isn't squeaky clean, and the "language" is less related
to markup than formal notation. Its perceived flexibility is really just a
consequence of its barbaric simplicity.

It's convenient for comments and blogs, but it damn well needs to stop
there. I can't count how many shitty manpages I've seen that have been the
direct result of automated markdown processing.

Ugh, don't get me started...

On 25 Feb 2018 4:19 pm, "Larry Kollar" <address@hidden> wrote:

> 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
its output might be. It depends mightily on macro packages feeding it hints
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 only
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

        *roff becomes an intermediate step from some other markup language
        an XML variant) on the way to PDF… or maybe manpages. In other
        documents check in, but they don’t check out. Frankly, I’ve moved
here from
        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]