Keiron, Sam, Sam Ruby wrote: > > Keiron Liddle wrote: > > > > About recent changes to batik. > > The interface change is probably not much of a problem but the is another > > problem with using the current cvs batik. > > The method getWidth on SVGOMSVGElement throws a runtime exception (due to > > recent changes), this is needed to get the width of the top level element > > (unless there is some other way) when render the svg in fop.
We will look into this and let you know as soon as it is clarified. I have entered a bug in Bugzilla for that 3684 as we may not be able to fix this without Stephane who is on vacation until next week. We will try though. > > Will this method be implemented for batik 1.1? or is there some other way > > to handle it. > > > > So at the moment some features of the cvs batik are needed but other > > features (regressions) cause it to not work. > > I'm not suggesting that anybody actually run with the batik from cvs, but I > am suggesting that the developers of batik be aware of the impact of > changes may have on others, and that fop developers be aware of such > changes. > > In this case, method signatures of a public interface were changed. A > public interface that fop implements. No deprecation. First, sorry for the inconvenience our code changes have caused. I did not realize that FOP was building off our CVS repository. We publish a change log with our releases and the major change Thierry and Thomas are working on will be detailed in the next developer release. What is happening is that we are fixing what we think was a design error and we are removing a parameter from a large number of methods in GVT, one of the core Batik modules. You are right, we are not deprecating the old signature, even though I agree deprecation is good practice. However, our change being such a wide change (i.e., there is a very large number of methods impacted), we think we should bite the bullet now and go on with a cleaner, leander API. There is inconvenience for some users (FOP is one), and we are sorry about it. Note, however, that this is not an API change in the most widely used Batik APIs (it is fair to qualify extending the TextPainter interface as a very advanced Batik API usage, but of course, this is not any argument for making that job even more difficult). Here is what I suggest: a. Short term, build using the batik 1.1rc2 release. b. Wait until Thomas completes the wide-spread changes Thierry has started (this will further impact the TextPainter interface). c. Once the API is stable again, update your TextPainter implementation so that it no longer uses GraphicsNodeRenderContext. d. Then, you can either use the Batik CVS again or use our next developer release. Again, sorry for any inconvenience. Vincent. > > See > >http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/gvt/TextPainter.java.diff?r1=1.11&r2=1.12&diff_format=h --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
