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