Re: [Groff] address@hidden: Re: Back to the future]

[Peter Schaffter]

On Fri, Mar 07, 2014, Eric S. Raymond wrote:
> Keith Marshall <address@hidden>:
> > 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