Re: [Groff] Future direction of groff

[James K. Lowden]

On Tue, 4 Feb 2014 15:43:11 -0500
"Eric S. Raymond" <address@hidden> wrote:

> I have to say, unfortunately, that I think the entire
> presentation-centric model within which groff lives just about run
> its course.  The future belongs to structural markup and stylesheets,
> because of the requirement for rendering in multiple output media
> including the Web.

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?  

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

> Cutting them loose from their groff-centric assumptions and making
> them generate more modern low-level formats like XSL-FO and SVG is a
> groff2 I could get behind 

Nothing stands in the way of another post-processor, groxslfo, right?
But then what?  What device recognizes that?  I know there's a
tremendous bunch of XMLy things, but generally they end up producing
Postscript or HTML.  The longer the chain, the more complex, and the
more difficult to promulgate formatting decisions.  

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?  

Margins?  Paper length?  Fonts?  I don't see how they stand in the
way.  On the contrary, the world would be a much better place if web
browsers natively rendered -ms macros (or similar).  It would make
writing documents -- and web pages! -- easier, and go some way toward
unifying the mess of formats and tools we use for technical
documentation.  

Take that one step further: suppose a version of xterm existed that
natively recognized ditroff instead of the boneheaded VT-100 standard?
Such a terminal could render printer-quality graphics in the
*terminal*, transforming assumptions (and experience) at the command
line.  

I'm sure there are some 1970's artifacts that could be dropped, and I
applaud (again) your insight that the input syntax need not be tied to
paper or PDF output.  But I'm not convinced that ditroff or its model
are obsolete.  In fact everything is a printer, just more or less.  

--jkl