[Top][All Lists]

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

Re: [Groff] Future direction of groff

From: James K. Lowden
Subject: Re: [Groff] Future direction of groff
Date: Tue, 4 Feb 2014 21:42:05 -0500

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

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

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

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.  


reply via email to

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