xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McCormack <cam-batik-...@aka.mcc.id.au>
Subject Re: RFC: Support for SVG 1.2
Date Fri, 12 Nov 2004 00:40:41 GMT
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


Mime
View raw message