On Fri, Mar 07, 2014, Eric S. Raymond wrote: > Keith Marshall <keithmarsh...@users.sourceforge.net>: > > you continue to convey an impression, real or imagined, that you believe > > groff's /raison de être/ to be man page production, which, of course, is > > a world apart from reality -- including the reality of your typographic > > instance above. > > You're imagining things. Calm down - neither I nor anybody else wants to > take your typesetting back end away from you.
There's still some misunderstanding--maybe mistrust--about Eric's agenda. It's why I recommended keeping the manpages debate separate from other discussions. Manpages are a subset of groff functionality, but they are a far-from-perfect tool for managing documentation because groff is the wrong tool. (Notice I say "managing documentation", not "writing documentation" or "reading documentation".) Nevertheless, they're embedded in Unix, and likely to remain so. Organization, indexing, and cross-referencing are essential to any documentation system (think stacks, the Dewey Decimal system, and card catalogues). Groff, however, does not concern itself with these things. It's presentational software. The API deals exclusively with typesetting. It's only when you bump things up to the macro level that semantic structuring becomes possible, which puts the onus for semantics squarely on the shoulders of macro writers. Frankly, the creators of the original man macros did a piss-poor job. But groff, the man macros, and the whole manpage system are legacy, and here to stay, so there's no point debating their inadequacies. Eric's project basically consists of prising manpage markup and manpage content apart, replacing the markup with a flexible system that preserves all the essential features of the original manpages while allowing them to be housed under one roof (the Web). Nowhere has he said the browser is an ideal presentational medium--it's not--but when it comes to all-under-one-roof, beautiful presentation is not the issue. We hardly expect a librarian to worry about typesetting when s/he's indexing and cataloguing a collection. That doesn't mean s/he doesn't love a good book, it just means s/he's on the job. I think this is what's confusing people. Eric's work is largely archival, and like any good archivist, he's not only trying to get the archive in order, he's thinking about the least restrictive way to make the task easier in the future. xml is open-ended and flexible, and furthermore entails the potential for rendering presentationally elegant content. We're all sitting here with our loupes and pica rulers, missing the point that poor rendering in a browser has nothing to do with input, and will improve with the decades. xml is the logical markup language for Unix documentation if it wishes to ride the train to that future while remaining useful and maximally accessible in the present. I really do think we're confusing policy with mechanism here. Eric's project has nothing to do with groff's backend or API. Of necessity, he must involve himself with groff because that's the stuff manpages are made of, but his involvement is, for all accounts and purposes, incidental. He's not trying to suggest formatting manpages should be groff's exclusive focus. I'm pretty sure he'd rather he didn't have to deal with groff for that purpose at all! His opinions expressed here about the paperless future may have been ill-timed, given that we're considering groff's future. It got everybody's back up and wound up with him being cast as an anti-typography, pro-semantic demon out to reshape groff in his own image. Just guessing here, and I'll let Eric defend himself on this, but I suspect, unless he's a rabid TeX devotee, that he's in our camp when it comes to typesetting with groff, and moreover, has no designs on the program itself at all. -- Peter Schaffter http://www.schaffter.ca
