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. 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.

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.

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.

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!

Jeremias Maerki

Reply via email to