Re: [Groff] Future direction of groff

[hohe72]

"Eric S. Raymond" <address@hidden> wrote (Tue, 4 Feb 2014 23:08:02
-0500):
> 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. 

Found
http://asciidoc.org/article.pdf
that shows the Table of Contents shifted to the right and I'm glad that
in using groff I can get ride of such artifacts (yet). They would
otherwise being addressed to be my faulty use of software.

> > 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.