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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
