groff
[Top][All Lists]
Advanced

[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: Wed, 5 Feb 2014 01:01:58 -0500

On Tue, 4 Feb 2014 23:08:02 -0500
"Eric S. Raymond" <address@hidden> wrote:

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

Yes, I know.  I haven't looked at it in a while, but I digested TAOUP.
I don't mean to slight your work.  

What I'm suggesting is that your AI system to create structure from
naught was necessary only because the problem is posed that way.
Nothing inherent in the English prose or the formatting instructions
requires the semantics or the nested-object syntax model.  Those are
imposed by your target, unfortunate artifacts of the misbegotten,
unsupported belief that documents need to be structured that way.  

I didn't ask you why it was difficult to conjure structure where none
was intended.  My question is much simpler: what about the troff
*model* of presentation prevents it from generating web-digestible
artifacts?  You say "groxslfo" is unnecessary work.  In your expert
opinion, why?  

To me everything on the far side of XML-FO is unnecessary work, as is a
fair bit on the near side.  Unless, I suppose, your goal is to plug
into that environment.  

--jkl






reply via email to

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