mirrors/fop - fop - source @ dussan.org

Jeremias Maerki cd600b952b 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	18 years ago
..
META-INF/services	Step 1 (SVN just doesn't want me to delete the old directories):	18 years ago
org/apache/fop/render	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.	18 years ago

Jeremias Maerki cd600b952b 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

18 years ago

META-INF/services

Step 1 (SVN just doesn't want me to delete the old directories):

18 years ago

org/apache/fop/render

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.

18 years ago