J.Pietschmann wrote:
> 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.

'font' is a super-set of font-family, and is the biggest parsing problem 
in property expressions.  Even being passed a comma-separated list of 
space-separated lists and individual items like the isolated '/' from 
PropertyParser, it was a nightmare to refine the 'font' expression 
parsing.  Without PropertyParser, the final parsing would have been 
outrageously complex.  Resolving and verifying property expressions is, 
I think, inherently a multi-stage process, and it is sensible to do as 
much generic handling as possible in the early, context-free, stages.

> But then, since you have working code which looks quite good,

Code, yes.  Working, no.  I hate dubugging huge chunks of code, but I 
have been all the time so close to becoming irrelevant to the project 
that I wanted to get the code written as soon as possible.

> I expect you to integrate it into HEAD rather than rewrite it
> again :-).

That will be difficult, but I haven't considered the problem yet. 
Unlike HEAD, which grew out of the existing code, mine has a completely 
different approach from the capture of SAX events onwards.  Properties 
are never instantiated, only PropertyValues.  When it's working, I'll 
have a look.

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

Looks promising, but it will take a lot of thought.

Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
"Lord, to whom shall we go?"

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

Reply via email to