Initial support for XMP metadata (PDF 1.4) under fo:declarations. Both xmpmeta and RDF elements can be used as root elements for XMP metadata.
Extracted DOM2SAX functionality from XMLXMLHandler into utility class since it is now reused elsewhere.
New DOMBuilderContentHandlerFactory is used to create ContentHandlers that build generic DOMs.
New DelegatingContentHandler is a convenience base class modelled after XMLFilterImpl but as passive SAX receiver. It is used by DOMBuilderContentHandlerFactory.
Refactored FOTreeBuilder. FO tree building is now in a special ContentHandler which can be replaced temporarily when handling foreign XML like SVG or XMP. Extension Elements wanting the set their own ContentHandlers (instead of using the standard FO tree building mechanism) return a non-null value in getContentHandlerFactory(). The old mechanism is still supported (MathML, Plan and Barcode4J still use that). However, SVG support is changed to use a ContentHandlerFactory.
Extension elements for xmpmeta and RDF elements making use of the new DOM build-up using ContentHandlerFactory.
XMP metadata is passed to the renderer as ExtensionAttachment to the document. Only PDFRenderer uses the XMP extension attachment at this time.
The PDFRenderer automatically builds XMP metadata based on the basic metadata information in the PDFInfo object if no explicit XMP metadata has been added to the XSL-FO document.
XMP metadata merging is not implemented because this would involve a more sophisticated XMP infrastructure. That also means that XMP metadata is not validated. It's passed into the PDF as is.
The PDF library now provides the PDFMetadata class to embed XMP metadata in PDFs version >=1.4. stream contents use a special filter list which is initially empty, so non-PDF-aware XMP readers can extract (and optionally modify) the XMP metadata.
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@378482 13f79535-47bb-0310-9956-ffa450edef68
XMLHandler interface changed so it reports whether it supports a particular Renderer instead of reporting the MIME type. One MIME type could be implemented by multiple Renderer implementations so conflicts could occur. Almost all XMLHandler implementations will have a dependency on a particular Renderer implementation.
XMLHandlers are now configurable.
Standard XMLHandlers now get registered through service lookup.
Simplification: XMLHandlers don't need nested classes for the handling functionality anymore. If Batik, for example, is not in the classpath it will already be detected while registering the XMLHandlers.
The RendererContextConstants interface now standardizes some of the keys used in the RendererContext and helps with actually decoupling the XMLHandler implementations from the renderers. This is one step towards making Batik an optional dependency and making it possible to move the SVG functionality to a separate place later.
Extracted the SVG XMLHandler functionality from the sandbox SVGRenderer into a separate class following the example of the other renderers.
Bugfix in PSSVGHandler: Fixed a copy/paste error which could lead to wrong clipping of an SVG image for PostScript output.
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@357166 13f79535-47bb-0310-9956-ffa450edef68
Updated from Jakarta Commons IO 1.0 to 1.1. CopyUtils.copy() becomes IOUtils.copy() again. CopyUtils in 1.0 was not ideal design decision.
Fixed most of the unappropriate System.err/System.out/Exception.printStackTrace(). Those that aren't fixed and are not legitimate calls (in main() methods etc.) are marked with a TODO item.
Some Javadocs and style updates.
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@344111 13f79535-47bb-0310-9956-ffa450edef68
Made Service a stand-alone class so it can be reused.
Made XMLHandler discoverable through the Service class.
Moved XMLHandler collection into new XMLHandlerRegistry class.
Adjusted the Renderers and XMLHandler to the above changes.
This should make it easier to write certain FOP extensions. The changes were triggered by my work on the FOP extension for Barcode4J for the FOP Trunk.
git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@225143 13f79535-47bb-0310-9956-ffa450edef68
Vincent Hennebert
Jeremias Maerki
Chris Bowditch
Keiron Liddle