This doesn't appear to be Batik's fault--they're just
recoding their classes, and their GraphicsNode
interface has two more functions in it, one of which
needs implementing in FOP's PDFJpegNode class.
If Gump links to Batik's latest and greatest when
building FOP, then FOP will need to update whenever
Batik changes. Could/should that be changed so Gump
will only link to the Batik library that we get on a
cvs checkout?
Thankfully, it appears that if this is added to FOP's
PDFJpegNode it will at least compile against both
versions--library Batik and latest-and-greatest Batik:
public Rectangle2D getSensitiveBounds() {
return getGeometryBounds();
}
(code from
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/gvt/TextNode.java?rev=1.27&sortby=date&content-type=text/vnd.viewcvs-markup
-- a Batik class that needed changing itself as a
result to the new functions in GraphicsNode)
Glen
--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> Hi Batik-Devs,
>
> the latest changes in Batik broke both the
> maintenance branch and HEAD
> of FOP:
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
