Hmm, turns out that I couldn't handle RDF/XMP without some major work
with the existing approach anyway. Too many namespaces and prefixed
attributes which XMLObj just doesn't handle right. And then the static
HashMap (unsynchronized!!!) of namespace prefixes. Argh.

On 15.02.2006 15:01:52 Jeremias Maerki wrote:
> 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.
> [1]
> Jeremias Maerki

Jeremias Maerki

Reply via email to