> John Gardner <gardnerjo...@gmail.com> 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