Jeremias Maerki wrote:
Don't be shy! This is actually quite easy. It just took the following
lines to hack that missing feature in. Just place the code snippet below
in SVGRenderer in the method renderImageArea() right after the commented
call to graphics.drawImage().
You're right, that seems to work fairly well for our simple case. I just had no idea how the renderer / SVG stuff stuck together.
But actually, I found another way which seems to require less effort on the part of FOP. Since we're including Batik for other features in our app, we already have access to Batik's SVGGraphics2D class which implements an AWT graphics context that "paints" to SVG.
I can use the AWTRenderer, and "print" each page directly into an SVG file, which people at work seemed to prefer anyway. And AWTRenderer seems much more mature, as it worked flawlessly (a nearby observer couldn't tell the quality difference between the SVG file opened in Illustrator and the equivalent PDF file opened in Adobe Reader.)
Bonus advantage: our code is now more or less identical (it differs in how the graphics context is created) whether we're rendering to SVG or TIFF.
I was getting to thinking how the SVGRenderer could even be implemented while reducing duplication of code, by delegating to the AWTRenderer. I'm sure there must be a little quality degradation by doing so, but I can't tell from our simple use cases. :-)
Daniel
-- Daniel Noll
NUIX Pty Ltd Level 8, 143 York Street, Sydney 2000 Phone: (02) 9283 9010 Fax: (02) 9283 9020
This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this message or attachment is strictly prohibited.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
