I'm seeking additional opinions on the following:

The most important motivation for the new intermediate format is "more
performance" for those who produce their print files based on
prelayouted documents (without noticeably slowing down the direct
rendering path, i.e. without intermediate format). Parsing the area tree
XML format proved to be relatively slow. In the case of extension
attributes, for example, they have to be identified as such and are put
into a Map defined in AreaTreeObject. The renderer can then check the
area object if there are any supported extensions and act on them. With
the new IF there is no longer an object that holds those extension
attributes. Similar to SAX, the XML content is transformed to method
calls directly.

For extension elements, there is
IFDocumentHandler.handleExtensionObject(Object) which is fine and does
its job well enough as it turned out during the implementation. I still
have to buffer some of the objects until the process reaches the right
point in time where the extension objects are actually used. But the
impact is quite insignificant.

What I'm currently trying to figure out is the best way to handle the
extension attributes. There are several possible approaches:

1. Add a Map or Attributes parameter to each applicable IF method. If
it's a Map, it has to be built from an Attributes instance coming from
the XML parser (when IF is parsed). That costs time and is undesirable. Or
if it's an Attributes instance, I have to build that up in the case we
paint directly from the IFRenderer. That also costs a bit of time
although that conversion is less significant when compared to the whole
process. But the approach also clutters the API a bit with things that
are not used in most of the cases.

2. Pack each extension attribute in a call to
handleExtensionObject(Object). A possibility, but I will need additional
tracking to associate an extension object with the actual IF element.
For a page I'd have to do startPage() followed by zero or more
handleExtensionObject() calls and make sure the extensions are properly
handled. It would also make the IFSerializer more complicated and the
IFParser still has to actively split IF namespace and other namespaces.
That can't be it.

3. The IFDocumentHandler/IFPainter pair gets access to a "context"
object where it can access to the currently applicable extension
attributes. The context object would play adapter for the two different
extension sources: Map from the area tree and Attributes from the
IFParser. That would avoid any additional processing especially if no
extension objects are present. The context object would be set on the
IFDocumentHandler at the beginning.

4. is a variant of 3 in which case the foreign object adapter would be
available through a ThreadLocal.

Personally, I prefer option 3 as it's the easiest to understand. In this
case, I'd probably remove set/getUserAgent() in favor of
set/getIFContext() and provide access to the user agent through the
IFContext to avoid cluttering the IFDocumentHandler interface.

Any other opinions or additional ideas? If I hear nothing I'll implement
option 3.

Thanks,
Jeremias Maerki

PS: Happy Xmas!

Reply via email to