On Wednesday, October 27, 2004, 1:49:18 PM, Thomas wrote: TD> Hi Chris,
TD> Chris Lilley wrote: >> What is required to make a custom build of Batik such that some elements >> and attributes, which were previously in the Batik extension namespace >> but are now part of the SVG 1.2 spec, can be tested in the SVG >> namespace? TD> The simplest thing would be to change TD> org.apache.batik.extension.svg.BatikExtConstants.BATIK_EXT_NAMESPACE_URI TD> to be the SVG namespace and do a clean rebuild (this would put a few TD> non-svg 1.2 elements into the SVG namespace but that shouldn't TD> matter). I agree that shouldn't matter for this use case. To be clear, Batik did exactly the right thing putting this prototyping in na different namespace and requiring a different, extended jar to get at this functionality. But now, for testing, it needs to be experimentally moved into the SVG namespace on some builds, so that we can do interoperability testing. >> This is needed to run a modified Batik against the unmodified SVG 1.2 >> test suite. TD> If it is preferable I could deliver such a build to you Yes, that would be preferable to me, partly because you are way more familiar with it and also because you say: TD> (I could also include the color-rendering-space property support TD> patch in the build as well - which otherwise might be difficult for TD> you to integrate). Yes, it would. TD> Now that SVG 1.2 is getting close and it appears that Batik will TD> have a number of useful 1.2 features I will probably modify Batik TD> to support working with 1.1 or 1.2 SVG automatically. That would be great. Note that there is a version attribute on svg so this should be transparent to the user. -- Chris Lilley mailto:[EMAIL PROTECTED] Chair, W3C SVG Working Group Member, W3C Technical Architecture Group --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
