Huh... Should g2d.create() have duplicated the rendering hints? Because PdfGraphics2D doesn't. Sounds like this is an iText bug after all.
--Mark Storer Senior Software Engineer Cardiff.com #include <disclaimer> typedef std::Disclaimer<Cardiff> DisCard; -----Original Message----- From: Mark Storer [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2008 11:37 AM To: [email protected] Subject: trouble with BufferedImage hint with iText's PdfGraphics2D I don't think this is an iText issue or I'd be posting to that list instead. None the less, I thought it might be relevant so I mentioned it. Problem: I set the rendered image hint to my g2d, but still get a "Graphics2D from BufferedImage lacks BUFFERED_IMAGE hint" message: if (image != null) { g2d.setRenderingHint( RenderingHintsKeyExt.KEY_BUFFERED_IMAGE, new WeakReference<Image>( image ) ); } mapGraphics.paint( g2d ); g2d.dispose(); if (image != null) { g2d.getRenderingHints().remove( RenderingHintsKeyExt.KEY_BUFFERED_IMAGE ); } The problem, it seems, is that AbstractGraphicsNode.paint(Graphics2D) creates a new Graphics2D object when there's a clipping path. AgstractGraphicsNode.java, line 454 and on: if (clip != null) { baseG2d = g2d; g2d = (Graphics2D)g2d.create(); if (hints != null) g2d.addRenderingHints(hints); ... } The hints in my PdfGraphics2D object aren't being propigated to the AbstractNode's "hints" member variable, so aren't being passed on down the call stack. In writing this post, I ran across the "org.apache.batik.warn_destination" property, which solves my particular issue, but it would still be nice if the hint would propigate. Or is this just old news? --Mark Storer Senior Software Engineer Cardiff.com #include <disclaimer> typedef std::Disclaimer<Cardiff> DisCard;
