Among other things, I'm currently implementing support for XMP metadata
as part of my PDF/A-1 work [1]. XMP can consist of elements from a
number of namespaces which are not necessarily known beforehand,
especially since you can add arbitrary private extensions to XMP
metadata. With our current method you get warning messages such as the
following for unregistered namespaces:

WARNING: Unknown formatting object^CreateDate

When parsing SVG, I think there's a similar problem, if someone decides
to use foreignObject or RDF in the metadata tag. As part of the
AreaTreeParser I introduced the concept of a ContentHandlerFactory (util
package). This could also be used when building the FO tree instead of
dealing with XMLObj-descendants which are discarded after the DOM
element they generate is added to the Document on one of its ancestors.
I'm already using it there to parse SVG, MathML and Barcode XML. Doing
this would mean refactoring FOTreeBuilder a little. I imagine I can do
better than what I did in AreaTreeParser.Handler so far which still has
a number of "ifs" in the SAX event handlers. I would probably insert a
dispatching ContentHandler in front of the actual handler that builds
the FO tree. The impact on the normal FO tree building should be
minimal: it's only one additional delegation of the SAX event calls. I
can't tell how this will look in detail, yet.

Any objects about me going down this road? I can try to explain more if
the above is not clear.


Jeremias Maerki

Reply via email to