groff
[Top][All Lists]
Advanced

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

Re: [Groff] Eric Raymond on groff and TeX


From: James K. Lowden
Subject: Re: [Groff] Eric Raymond on groff and TeX
Date: Mon, 7 May 2012 15:06:17 -0400

On Sat, 5 May 2012 21:25:50 -0400
Steve Izma <address@hidden> wrote:

I found your story facinating, especially the observation that groff,
because it's a filter, is well suited to typesetting *any* input. One
might say groff provides an abstract printer in the same sense that Unix
provides an abstract machine.    

> Any white space at the beginning or end of such a
> block can be discarded and the proper spacing decisions turned
> over to the macro definition. An in-line element (emphasis, small
> caps, superior numbers) not only needs surrounding white space
> (or lack of it) detected and preserved, it also breaks up the
> enclosing block, leaving a tail (depending on the kind of parser
> you're using). 

What is "tail" here, please?  I thought I understood until then.  

> So far I have always needed to detect and define
> separately whatever in-line elements a document uses, which
> means that writing a general-purpose formatter for XML seems
> virtually impossible.

Why is it not possible to divide and conquer?  If we know the set of
tags and every tag is either block or inline (never both), why can't a
dictionary of tag properties permit uniform handling of all in-line
elements?  

--jkl



reply via email to

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