xmlgraphics-batik-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 Mon, 16 Aug 2004 20:26:47 GMT
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

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


>>    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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org

View raw message