Hello, I tried to clean up a bit in the maintenance branch, with focus on reducing memory load and improving performance. I'd like to discuss the following issues: - Java 1.2 containers (HashMap) sneaked into the maintenance branch during a merge of a minor feature from the HEAD I made some times ago. Question: there had been discussions about JDK 1.1 compatibility, however, HEAD uses 1.2 containers exclusively. Should we go ahead and replace 1.1 containers in the maintenance branch too? It should result in a (perhaps very slight) performance increase. The more important point is the following: - Merge HEAD PDF renderer. This renderer has been improved quite a bit, in particular with regard to some SVG features some people find important (and I promised frivolously to be included in the next maintenance release). Merging the HEAD PDF renderer into the maintenance branch seems to be possible. Should this be a goal for the next maintenance release? - I put some work into rationalizing the FO tree. In particular, the FONode top level class always creates a "children" vector, which means that everything, including FOText, can have children. A run on the FOP examples shows more than 45% of all nodes (includes text) having no children, another >40% having only one, so it seems to be a big waste. Another point is that in addition to the children, child nodes are often stored in typed members or other variables, for example none of the fo/pagination classes uses "children" at all. Another aspect of this mess is the abundance of casts and "instanceof" operators. In a well designed system which properly uses inheritance and polymorph methods, every cast except for return values of container get() are suspect. The correct method would be to add methods like setLayoutMasterSet() to FObj which throws a "illegal child" exception, override it in the classes (here: Root) where they set the correct variables, and use them in the constructors of the child FO to add themselves in a type save manner to their parent. This also checks for structural errors in the FO document in a nice way. The unfortunate side effect of this approach is that it interferes with the current "generic extensiblity" approach. With everything hardwired, extensions have to be somewhat hardwired too rather than just dropping in a class and registering a factory. It may be possible to have a hybrid approach with both a rigid XSLFO structure and a flexible mechanism for extensions, I've not come to a conclusion yet. It may be necessary to settle for certain extension classes: root extensions, and extensions subclassing an existing FO, for example <fox:page-count/> subclassing fo.flow.Inline.
Ok, to sum up (for voting, if someone wants to): - Java 1.2 containers in maintenance branch - merge PDF renderer from HEAD into maintenance branch (requires previous) - rationalize FO tree at the expense of making extensions Comments? J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
