Re: Property handling
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]
Re: Property handling
Peter B. West wrote: > There is a gotcha. 'font-size' > within a marker subtree has no parent at the time of XML parsing. The > same goes for everything else within the marker subtree. All resolution > in the marker subtree must be deferred until the subtree is "re-parented". I should have known I missed again yet another unpleasant but important issue. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Property handling
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]
Re: Property handling
On Wed, 2002-08-14 at 01:36, Peter B. West wrote: > J.Pietschmann wrote: > ... > > > Keiron Liddle wrote: > > > Does that mean we should not attempt to solve this problem? > > > Or that we should attempt to solve the problem twice independantly. > > > > Actually, this problem has been tackled several times already, in > > particular if we include Peter's efford, with no really satisfying > > solution yet. In part, this is due to some attempts to keep it as > > generic as possible, and to some sigificant degree also due to the > > hairrising complexity of the matter itself. I don't know that it has been tackled several times. I am mostly ignoring properties, I use what I can to get the layout going. As far as I am concerned Peter is working on properties. There are also a number of different areas to this problem. Getting properties to the FO tree, using properties in the layout and then setting traits on the area tree. > While keeping in mind the gotchas that are always lurking in this spec, > I am confident that I am almost at the point wher I can say that I have > developed a really *personally* satisfying solution for properties. By > satisfying I mean > 1) that it is complete; not that I have implemented every function and > expanded every shorthand, but that the framework I have in place will > handle anything that those unimplemented elements will throw at it. > 2) that it is robust; by which I do not mean that it conforms to best OO > practice, but that it works predictably, reliably and (see above) > completely. > > And yes, it is absolutley choc-a-bloc with instancesof and casts, which, > I have recently been led to understand, are expensive operations. What > a pity. It is a good reason for wanting to minimise them though. I > note that the received wisdom about efficiency in Java took a pounding > from Joerg's findings about the negligible performance impact of > replacing synchronized Collections with unsynchronized. That was > extremely encouraging news, and is presumably down to improvements in > the JVM. Synchronized collections only make an impact if common (ie static) structures are used in different threads. I had already replaced these and it made a huge difference, factor of 6 times with 6 threads. > > I myself take issue with: > > - Property handling is hard to understand, with a gadzillion of > > indirections and odd "instanceof" and casts and of course, the > > XSL generated code. > > - There are a lot of classes involved, sometimes with seemingly > > duplicated semantics. > > - The DirectPropertyList abomination. > > - In HEAD, there appears to be another batch of Trait classes which > > also appears to deal with data which the various Property are > > apparently used for. Traits are on the area tree, this is generally a subset and of different values than the properties. > > At first, there should be a clear distinction drawn between XML > > attributes and FO properties. > > So what's wrong with the following approach: > > - Pass the sax.AttributeList to the FO's constructor. Already done. > > - Have a FONode method which goes through the attribute list and > > + gets a PropertyMaker from a hash table the same way a FObj.Maker > > is retrieved and store it in a list, except for "font-size" and > > "font" which are processed immediately > > + walk the list and invoke a "parse" method with the XML attribute > > value, the FO and the parent Already done. Joerg, I think you are really proving my point. If we do this in one place it will be much better. Work from what is already done, passing attributes to the FONode etc. Do it once with a common goal in mind that doesn't leave us with difficult merging issues. Keiron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Property handling
J.Pietschmann wrote: > There should be no need to actually store for many properties most > of the data types which can be specified in an XML attribute, for > example font-size can always be resolved to an absolute value. Bad > things are for example alignment-adjust which must still store an > alternative of an enum, an absolute length and a percentage. 'font-size' is a special case in more ways than one, and even here there is an exception. *In general*, percentages cannot, or ought not, be resolved to absolutes at parsing. There are too many cases of percentages referring to outer reference lengths which are themselves dependent on layout decisions. 'font-size' is OK to resolve because a percentage refers to the parent 'font-size', and is therefore equivalent to an EM value. EMs themselves are *generally* OK to resolve immediately because 'font-size' is determined either absolutely or by inheritance in line of FO tree descent. There is a gotcha. 'font-size' within a marker subtree has no parent at the time of XML parsing. The same goes for everything else within the marker subtree. All resolution in the marker subtree must be deferred until the subtree is "re-parented". Peter -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Property handling
Peter B. West wrote: > J.Pietschmann wrote: > And yes, it is absolutley choc-a-bloc with instancesof and casts, which, Should read "absolutely chock-a-block"; it is not to be confused with the consumption of chocolate. >> - Have a FONode method which goes through the attribute list and >> + gets a PropertyMaker from a hash table the same way a FObj.Maker >> is retrieved and store it in a list, except for "font-size" and >> "font" which are processed immediately I didn't notice immediately that you had picked up that the 'font' shorthand must also be processed before others. The spec fails to mention it, as, in the relevant section, 5.9.2 Evaluation Order, it fails to mention the ordering requirements of shorthands, compounds and their expansions. Peter -- Peter B. West [EMAIL PROTECTED] http://powerup.com.au/~pbwest "Lord, to whom shall we go?" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
