DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=37305>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37305 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-30 22:04 ------- Created an attachment (id=16838) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16838&action=view) Patch to add support for a 'deviceDPI' other than 72. This patch manipulates the transforms in the PDFGraphics2D so that if people want to query the 'device DPI' (as Batik does when rendering images/filters/etc). They can get a number other than 72DPI (the default PDF DPI). It works by adding a scaling transform to the PDFGraphics2D, and a reciprical 'hidden' transform to the PDFGraphicsState. Thus if code asks the Graphics2D for it's Transform (which should be the mapping to the 'device' coordinate system) they will see the scaled coordinate system (likely making it appear that the device is say 150 or 300 DPI). But the 'hidden' transform will then map everything back to the PDF default 72DPI. The only issue I am aware of is that currently the PDFGraphics2D doesn't call preparePainting in _every_ method. So in particular some methods like 'clip' could take place before a page has been started. I think this is likely an oversite in the PDFGraphics2D implementation. However in the mean time I've added a call to preparePainting in the PDFTranscoder after all the configuration is done so that the needed transforms are present immediately. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.