Jeremias Maerki wrote:
The limitation to 72dpi in the PDF transcoder has the undesired side effect of outputting embedded images in a very low quality. Removing it improved quality a lot here.
Yah, my original thought was to have the PDFGraphics2D rasterize at something like 150-300dpi (configurable of course) but provide an initial transform of 1 unit = 72 dpi.
see above.
I actually believe that this would help other user communities. Unlike Batik/SVG where we are happy to work with a Graphics2D where the default mapping is 150 or 300dpi most applications will just wig out (they assume the Graphics is ~72-96dpi). For them to generate high resolution images the PDF Graphics needs to internalize this transform.
So the idea is that one unit maps to 1/72 or 1/96th of an inch, but if you ask the Graphics2D for it's transform it would return something like a scale by 4 (i.e. the the device has 4 pixels for each user space unit). The tricky bit is that it then internally needs to remap objects drawn in this artificial 300dpi coordinate system to the PDF 72dpi coordinate system (essentially it contains a second 'hidden' transform that maps the 'device' space to PDF space).
This system will "trick" well written applications into rasterizing content at 300dpi without having to be setup to scale all other drawing operations. This is what the current Print Graphics instances do. The scale factor should of course be configurable.
To answer your question in this case you can ask the root GVT node
for it's bounds (getBounds()). In the case of a dynamic document you
can use getBBox() on the DOM nodes (but that generally doesn't apply here). This is the true geometric bounds of the document but often
this isn't really what people want - which is why it isn't a good
idea to just use it anyways.
I agree that the document is in error. It is assuming that all user agent's will use 96 pixels to the inch for real work conversion. This is a bad assumption, in SVG you must include a viewBox if you want to ensure your content will show properly in the useragent's window.
Ok, but that means we could (!) provide an optional convenience mechanism for the user to have his faulty SVG display correctly if he can't (technically) fix his SVG. I'll try that.
You could add a 'fit to page' type functionality. Personally, I would rather encourage people to always include a viewBox attribute, for almost all documents it is likely an error/oversight that no viewBox is included.
1) It looks like a JDK 1.4 dependency has slipped in: java.lang.IllegalArgumentException: Illegal pattern character 'Z'
Yes. I will see to that. FOP officially still targets JDK 1.3.x, too, although some would like that requirement dropped. In that case I will see to it that the Batik-relevant parts remain 1.3-compatible for the time being.
Thanks!
2) I was going to commit a patch that adds support for anti-aliased clipping (for shape-rendering="geometricPrecision"). However this may result in a lot more content being rasterized. This isn't a big deal within Batik but for transcoding this loses a lot of semantic value. So I will likely add a method to the UserAgent to check if the user agent want's it to use anti-aliased clipping or not.
Does this sound like an acceptable solution?
Sounds good to me.
Ok, I'll work on this. The more I consider it I suspect that a custom RenderingHint may work better.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
