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. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
