xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: PDF Transcoder: Revisiting transcoder setup
Date Sun, 15 Aug 2004 20:53:16 GMT
Jeremias Maerki wrote:
> 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/BrowseList?listName=fop-user@xml.apache.org&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?

Mime
View raw message