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

[Larry Kollar]

> John Gardner <address@hidden> wrote:
> 
>> 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.

Good luck!

>> you can take [Markdown's] squeaky-clean HTML output and transform it into
>> *anything*.
> 
> 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.

I’m typesetting entire books out of Markdown (specifically, MultiMarkdown).
The path is MMD -> XHTML -> EPUB -> XSL -> FO or *roff. The HTML I’ve
seen to date has been excellent. EPUBs validate without a hiccup, and I
take the same XHTML and transform it to FO or *roff for print.

If automated processing is creating bad manpages, I’m guessing the input
documents aren’t written like manpages in the first place. If you’re starting
with a document written with -ms macros, you would run into the same issue
if you want to make it a manpage — how do you determine what to put under
NAME, SYNOPSIS, and the rest? Getting the NAME string right can be an
art in itself; it has to make sense to the reader while including good keywords
(metadata) so apropos can find it.

In short, if you want a good manpage from automated processing, you have
to start with something that looks like a manpage.

        Larry