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.
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. > 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. > > 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. > - 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 > - The parser gets the parse context from the FO and parses the > attribute value in a more or less customised way. 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. There is a refinement/verification stage which is property specific, in which expression results are checked for type and range. But even at this point, there is, except in isolated instances, a range of possibilities. > - Once a property is parsed, resolve the value as far as possible and > tell the FO to store it. Keep a bit whether it was already set for > conflicts with shorthands which may be evaluated later and for the > "get-nearest-specified value". The latter information can be > discarded in the FO's end() method (which is underutilised anyway). > 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. > > There are, naturally, concerns that if every property is stored in the > FO, it becomes large. An idea to solve this is to create bundles of > properties which are likely to change together, as already partially > done in FontState and other objects, check after property resolution > whether a bundle with the same values has already been used elsewhere > and reuse this. Some of these bundles, in particular FontState and border > settings can be passed through the areas to the renderer, which might > even improve or simplify reuse of objects there. > I think I posted already that for the "franklin_2pageseqs" example > more than hundred FontState objects are created, while there are only > three different combinations of values. > The problematic point is to choose the bundles wisely: if they hold > too many or too unrelated properties, there wont be much reuse; if they > are too small, there is no gain because the references to the property > bundles still take memory. I had to abort a few attempts at designing > them because my brain seems to be too small to handle this :-( Which says something about the feasibility of this approach. If someone of your talent can't make it work, it doesn't look good. You might try applying a little more of the magic ingredient - time - before abandoning it, but, prima facie, it applies only in very specific circumstances, like FontState. > I tried to implement this for text decorations (TextState), actually > there can be at most 8 different value combinations (disregarding > "blink"), so I preconstructed these and had the PropManager select and > return the appropriate TextState object. Interestingly, this seemed > to *increase* memory consumption of the test run, despite, of course, > much less TextState objects are constructed. I'm still stumped. It might be useful to look at .../fop/datatypes/TextDecoration.java and TextDecorator.java in the FOP_0-20-0_Alt-Design branch for another approach. 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]
