Paul Belleville wrote:
Thanks.  Yes, Paulo mentioned some very large numbers in the PDF.
So, where do you think the issue is?  jFreeChart or iText?
Can you think of any work-around I can do now? before the patch comes?
Paul Belleville

Java2D uses double primitives to specify geometric "shapes" (rectangles, lines, ellipses etc.) but, as far as I know, doesn't specify anywhere what the valid range of coordinates (at rendering time) is.  If there is some underlying limitation (as there appears to be in PDF) then I'd expect the Graphics2D implementation to "clip" shapes appropriately to avoid errors, so in that sense you could say it is a problem with the PDFGraphics2D class.  That said, there are similar problems in Java's own Graphics2D implementations, so it isn't a well-specified area (or, if it is, I've not seen the specification).  I suspect that providing a bullet-proof Graphics2D implementation might incur a performance penalty from checking and clipping every shape before it is drawn...but I don't really know, since I prefer to stay on the user-side of the API (the low level implementation of the API is very complex).

I think the problem needs attacking from both sides --- if we can make PDFGraphics2D more robust without harming performance too much, let's do it.  At the same time, I'd like JFreeChart to work as well as possible with existing versions of iText (since people are slow to upgrade libraries in my experience), so putting some workarounds into JFreeChart makes a lot of sense as well.  The type of workaround needed is to add some basic "clipping" to the JFreeChart renderer, so that it never sends really extreme coordinates to the Graphics2D implementation in the first place.

As a starting point, I'd like to look into your failing example, so if you are able to distill it into a self contained test case that would be great...