Hi all,
This is to document the changes I have made to support SVG 1.2
and SVG 1.0/1.1 in Batik.
The goal is to as much as possible keep SVG 1.2 code out of the
SVG 1.0 support, while at the same time letting the SVG 1.2 code
leverage the 1.0 code as much as possible.
There are four major pieces to Batik's support for features of SVG:
1) DOM - This is the SVG DOM element interfaces. Also
Batik will reject as invalid any document that
includes elements in the SVG namespace that it
doesn't know about.
Primary 'control' interface: DOMImplementation
2) CSS - This handles the CSS properties that SVG uses. A
couple of new properties are needed to support SVG
1.2.
Primary 'control' interface: CSSEngine
3) Bridge - Maps DOM elements into the Graphics tree (GVT).
Primary 'control' interface: BridgeContext
4) GVT - The Graphics tree. New elements are likely to
need new graphics tree node types.
Primary 'control' interface: None
Towards this end I have introduced a number of new subclasses
and packages:
New Packages:
batik/bridge/svg12
batik/css/engine/value/svg12
batik/dom/svg12
gvt/svg12 (I don't like this as GVT is supposed to be svg
agnostic)
DOM Specifics:
Right now there is an SVGDOMImplementation and a class called
ExtensibleSVGDOMImplementation. This was problematic for adding
SVG 1.2 since you really want SVG12DOMImplementation to derive off
SVGDOMImplementation but you don't want to replicate the work of
ExtensibleSVGDOMImplementation. As a result there is now
o.a.b.dom.ExtensibleDOMImplementation which is a baseclass for
SVGDOMImplementation, and SVG12DOMImplementation derives off that.
This still needs some work, but I plan to add an alternate
interface to SAXDocumentFactory that allows one to pass in a
DOMImplementationSelector which is called with the information
from the first 'startElement'. In our case we will look for the
root element to be an svg:svg element and check the version
attribute to see if it is "1.0", "1.1" or "1.2". When it is
"1.2" we will use the SVG12DOMImplementation.
CSS Specifics:
Right now there is a CSSEngine that does all of the CSS work
and SVGCSSEngine derives off that and mostly just provides an
appropriate list of Properties. SVG12CSSEngine will simply subclass
the current SVGCSSEngine to provide SVG 1.2 properties and shorthands
as needed. Because the CSSEngine is built by the DOMImplementation
it is easy for the SVGDOM and SVG12DOM Implementations to construct
the appropriate subclass.
Bridge Specifics:
Right now all the SVG 1.1 bridges are registered by something
called the SVGBridgeExtension. I've created a subclass called
SVG12BridgeExtension. Right now the selection (based on the
version attribute) is hard coded into the BridgeContext. I may move
this to a method on the bridge.UserAgent.
GVT Specifics:
Not much really interesting here. I've put any new graphics nodes
or graphics related code in the svg12 subdirectory.
Most of these changes shouldn't effect people. The changes I
think might effect people are the changes to the DOMImplementation.
In particular there is no longer an ExtensibleSVGDOMImplementation
(this is what SVGDOMImplementation is) - if there was interest I
could preserve the class as an empty subclass of SVGDOMImplementation.
I'm not worried too much about this since I suspect that most
people only use the SAXSVGDocumentFactory to construct documents.
What do people think should I preserve this class?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
