Maintenance: Java 1.2 Containers, HEAD PDF Renderer

[Joerg Pietschmann <jo...@zkb.ch>]

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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: Maintenance: Java 1.2 Containers, HEAD PDF Renderer

[Keiron Liddle <ke...@aftexsw.com>]

On Mon, 2002-07-29 at 10:45, Joerg Pietschmann wrote:
> 
> 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:

There is no good reason to stick with the 1.1 containers.

> - 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 presume you mean the pdf library code and the svg code (I still need
to do a bit more on the text painter).
The changes involved here are not trivial or isolated. It includes the
image handling, fo tree setup (how external xml is handled, attributes
etc.), renderer setup and area tree.
It almost sounds like HEAD with the old layout (if only we could have
HEAD with the new layout...).

If you think it is worth then effort then go ahead.

> 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: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org