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!