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-11-10 02:48 ------- (In reply to comment #2) > I've got a question on this one: How does the setDeviceDPI() relate to the > resolution setting in the user agent? So far I was able to set a different > resolution on the user agent to get PDFs with higher resolution on-the-fly > images. This working depends heavily on the way the SVG is constructed, also it can have some very unexpected (read harmful) results. The pixel per mm setting is used to map 'real world' units (like in, mm, pt, px - yes px is a "real world" unit in SVG because it's defined == to pt) to user space units. So in the default case let's say we have the User Agent setup so 1pt == 1 user space unit (1in = 72 user space units), and you have a 'good' outermost SVG element: <svg width="8in" height="10in" viewBox="0 0 576 720 xmlns="..."> In this case your width and height establish a 'device' image size of 8*72x10*72 (576x720) user space units. Since the viewBox is the same size there will be no scaling. Now if you were to set the mapping to say 144 user space units to the inch. Then the device image size would be 8*144x10*144 (1152x1440) user space units. However the viewBox would scale this back down to 576x720. The PDF transcoder adds a 'hidden' scale from the PDF page size to the 1152x1440 page size (much as my code does). So far everything looks good, but the problem is that when someone says <text font-size="12pt"/> this gets mapped to 24 userspace units instead of 12 userspace units. > I'm not sure but it seems that this isn't working properly anymore. > Can't tell when this went lost. And AFAICS setDeviceDPI() is not called by the > Transcoder. Is that by design? I'm a bit lost. You are right that it isn't currently called. The problem is that it should really be exposed as a new rendering hint. In my patch I didn't change the 'default' DPI but it should really be set to 150 or 300 dpi. > Concerning preparePainting(), we may need to add additional calls where > necessary. I've added this method to support multi-page PDFs from > PDFDocumentGraphics2D. I'm using it in a JPS StreamPrintService where > you don't know beforehand if the next page will be produced or not. > A call to nextPage() finishes the current page and a new one can > only be set up when painting begins. So for single page SVGs from > the Transcoder, your change is fine, but we may need to add additional > calls where needed. I'll have a look when I start moving the > transcoders as I will publish my JPS StreamPrintService at that time. I strongly suspected that the missing calls were an oversite, but before making such extensive changes I wanted to make sure. -- 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.