xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: RFC: Support for SVG 1.2
Date Sat, 13 Nov 2004 03:11:28 GMT
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

>>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

View raw message