[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Future direction of groff

From: hohe72
Subject: Re: [Groff] Future direction of groff
Date: Thu, 6 Feb 2014 13:36:57 +0100

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]