DO NOT REPLY [Bug 37305] - Added deviceDPI to PDFDocumentGraphics2D

[bu...@apache.org]

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 deweese@apache.org  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.