Re: [Groff] Future direction of groff

[Eric S. Raymond]

James K. Lowden <address@hidden>:
> Hmm, seems to me every document is presentation-centric, depending on
> what that means.  Are you suggesting Postscript and PDF are not long
> for this world?  Are we doomed to the eyesores produced by
> lousy-browser ebook readers?  

Oh, no.  I think Postscript/PDF have a *long* future ahead of them.

What I don't believe is that there will ever again be enough demand for 
printer-*only* output to justify markup formats and toolchains that don't
also do web and ePub or functional equivalent.

I lean heavily on asciidoc these days. It's been years since I wrote
anything in [nt]roff; instead, if that's needed, I use a stylesheet to
make [nt]roff from asciidoc.

Bear in mind that I've been pretty good at [nt]roff since around 1982 and 
a groff contributor since...um, 1992 or thereabouts?  So it's not like I 
don't know the [nt]roff model intimately.  I do, and I think it's headed the
way of the quill pen and the slate, and I won't miss it much when it goes.
I have better tools now; troff is just another intermediate output format.

I'd miss pic, though.  I like pic.  I'd like to decouple pic from troff
and save it.  That would take some redesign near font specifications.

> > The one thing I thing we could usefully salvage from the groff model
> > is the notion of stacked DSLs for special formatting tasks - pic, eqn,
> > grap, chem and the like.  
> 
> Yes, yes!  Say it, bother!  Rebarbative it may be, but at least troff
> syntax was intended human beings to use.  

Sorry, I think asciidoc syntax beats the crap out of troff syntax along
every axis, including usability. Time passes. Progress gets made. 

> Nothing stands in the way of another post-processor, groxslfo, right?

No, but it's unnecessary work.  I think the energy would be better
spent making fop work and making every former groff preprocessor speak
XSL-FO.  And making stylesheets that really sing.  And native UTF-8
all the way through.

> I wonder what presentation-centric -- I think you mean "paper-centric"
> -- features troff is beholden to.  What is different about nonpaper
> devices, that prevents troff by design from producing documents for
> them?  

Oh, Goddess.  Page one, chapter one...go take a long look at doclifter.

Contemplate the huge baroque baby AI I had to write to extract decent
structure from troff markups.  Those "page-centric" assumptions go way
deeper and cause way more problems than you realize. I speak with
authority here, having been the guy who *solved* this problem after
the XML-Docbook crowd told me it was impossible.

They were wrong, but they weren't far from being right.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>