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. > 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. 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 . An example of the types of problems this causes: coccon has support for both batik and fop. If fop decides to hold back on supporting the next release of fop for a while and standardize on the current release, then cocoon will either have do to likewise or temporarily drop support for fop. Thats why I strongly believe that changes to public interfaces merits public discussion. - Sam Ruby --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
