Peter B. West wrote:
> More less than more, I should think.  Parsing is inherently "generic". 
> E.g., I assume that you would use the same tokenizer and first-level 
> parser.

At the tokenizer level, sure. However, the spec provides for
a wildly varying spectrum of grammars, there are aritmetic
expressions, whitespace separated lists, and, just to avoid
boredom, a comma separated list for font-family. Of course
you can build a parser which copes with them all, but I thing
it doesn't make much sense to expect a arithmetic expression
in a text-decoration value.

But then, since you have working code which looks quite good,
I expect you to integrate it into HEAD rather than rewrite it
again :-).

> > The problematic point is to choose the bundles wisely:
> Which says something about the feasibility of this approach.

Well: FontState, the few properties specific to fo:character,
hyphenation, vertical alignment related stuff, border color+width
and style (can be passed unchanged to the renderer), border
conditionality+padding, background related including bg color,
fg color, whitepsace+linefeed treatment+wrap, line specific (hor.
alignment + maybe something else), block only properties (overflow
etc.), table specific properties, table colum specific properties,
text decoration.
Position, keep-*, break-*, geometry and most of the rest don't get
bundles but are stored directly.
Just a thought.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to