Thomas (and all),
I'm currently tracking down differences between the PDF and PS transcoders. The following thread triggered that: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=825221
There's an SVG attached to the first post. It's a SVG with width and height specified but without a viewBox. In the EPS transcoder the file showed correctly, at first. At least until I changed the resolution from 96dpi to 300dpi. The PDF transcoder did the whole thing wrong because it's now working at a fixed 72dpi as per your patch: http://marc.theaimsgroup.com/?l=fop-dev&m=106795227230411&w=2
I didn't question that patch back then, but I'm now curious why you
think it is necessary to use a fixed resolution. You say it's the
default user space of PDFGraphics2D. I'd say there is no resolution in
PDF, only the resolution at which some SVG constructs will be rendered
as bitmaps when they cannot (yet) be expressed natively.
This is almost right. The problem is that the PDF transcoder starts with one userspace unit equal to one 'pt' (1/72nd of an inch). Without my patch the generated PDF files for documents that specified a size using a real world unit were off by 96/72. I suspect that your EPS files will have similar issues.
In the EPS transcoder I've managed to make it work at every resolution in the meantime (fixes not committed, yet) by generating the right initial
transforms. I believe this can be applied to PDF, too.
Yes, I suspect that we could fix this by adding a scale by 72/getPixelUnitToMillimeter() before rendering the document (My original thought was to have the PDFGraphics do much of this work, which might have some advantages but would be a lot more work).
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.
But I still have one problem with the above SVG file without viewBox. In the PDF transcoder the images is too big. If I manually put a viewBox="0 0 533 266" into the SVG file then it comes out correctly in PDF. Obviously, the SVG file is made for a 96dpi environment which explains the behaviour. A solution to this problem would be if I could ask Batik to give me the effective (outermost) viewBox even if none is available. Does something like that exist? I didn't find anything.
This would be a violation of the SVG specification. You should not
'create' a transform where the user has not requested one. The one place you might use something like this is if the user does not
provide a width and height - in this case the user agent is free to
select one.
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.
Sorry for the long post. I'm not sure I understood the whole thing completely and I'm hoping you (or someone else) might have some additional ideas. Thanks!
Looking at this raised two new issues for me.
1) It looks like a JDK 1.4 dependency has slipped in:
java.lang.IllegalArgumentException: Illegal pattern character 'Z'
at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:472)
at java.text.SimpleDateFormat.format(SimpleDateFormat.java:432)
at java.text.DateFormat.format(DateFormat.java:300)
at org.apache.fop.pdf.PDFObject.formatDateTime(PDFObject.java:231)
at org.apache.fop.pdf.PDFInfo.toPDF(PDFInfo.java:159)
at org.apache.fop.pdf.PDFObject.output(PDFObject.java:150)
at org.apache.fop.pdf.PDFDocument.output(PDFDocument.java:794)
at org.apache.fop.svg.PDFGraphics2D.drawImage(PDFGraphics2D.java:505)
Can this be fixed? Batik still targets JDK 1.3.x.
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?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
