You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2004/11/12 01:00:56 UTC
RFC: Support for SVG 1.2
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RFC: Support for SVG 1.2
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Cameron,
> Hi Thomas.
>
> Thomas DeWeese wrote:
>>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)
Cameron McCormack wrote:
> 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.
This was one driver. Also I wanted to really try and keep
1.0 and 1.2 code separate, it's really easy to accidentally add
dependencies (and consequently behaviors) when they live in the
same package.
> 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?
There _will_ be some of this. One thing I'm not sure of is how
much value there is in supporting 1.0/1.1 as something separate.
Batik has in the past gone to great lengths to try and conform to the
specification, including issuing errors where many UA's would let
things pass (like unknown elements in the SVG namespace). To
continue this I think it would be important to keep the code
separate.
>>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.
Well I don't know why registerSVGBridges wasn't a member function
to start with (it is _very_ odd to have a static function that takes
as it's sole argument an instance of the class it is a static in ;).
I didn't want to introduce an SVG12BridgeContext because I think
a fair number of people create there own BridgeContext and all of
them would then have to have the version checking code. My eventual
plan will probably be to add a service interface for this so people
can turn off one or the other easily.
Also heads up Cameron, making the loading/section of the bridge
extensions non-static, rippled into the dynamic checking which
also used to be static. In the end I think it will be transparent
but since you did work in that area I thought I would warn you.
I also had to tweak the order of bridge context creation in
the Canvas objects.
Finally, I was thinking about it and I'm leaning towards making
the default state of the canvas ALWAYS_DYNAMIC. Squiggle will of
course reset it to AUTO, since in this context AUTO _always_ does
the right thing. But it would mean that _most_ java people would
probably get what they wanted, and in the worst case it will be
just a bit less efficient than it could be.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: RFC: Support for SVG 1.2
Posted by Cameron McCormack <ca...@aka.mcc.id.au>.
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