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]
