Hi Thomas. Thomas DeWeese: > 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.
Yes, this seems like a good idea so that version attribute checking is done only once, and appropriate classes constructed. > 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) I wonder though if it is really worth having separate packages for the SVG 1.2 support. The only reason I can think of (off the top of my head) would be to make it easier to leave out the SVG 1.2 support from a distribution, if that was wanted. Unless you think there will be many subclasses of the existing SVG 1.0/1.1 classes to add a little SVG 1.2 support to them. I haven't really thought about it: would this be likely to happen? > 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. That seems ok. > 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. Yep. > 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. Why not make the registerSVGBridges/getBridgeExtensions methods non-static, and then have a SVG12BridgeContext class that overrides getBridgeExtensions to use the SVG12BridgeExtension? The JSVGComponent.createBridgeContext method would have to look at the version attribute on the document that's about to be used. > 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? I obviously can't speak for everyone, but I think you are right that people aren't likely to have constructed their documents directly from the ExtensibleSVGDOMImplementation. Cameron -- Cameron McCormack | Web: http://mcc.id.au/ | ICQ: 26955922 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
