Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without fully loading it

Of course, that means that someone has to have a deeper understanding of
a bitmap format to be able to write the code that extracts the necessary

On the other side, the Batik codecs actually parse the resolution
information. For PNG, see parse_pHYs_chunk() in [1]. Unfortunately, it
doesn't expose that information. It's interesting to note, that
PNGImageDecoder [2] does almost the same as PNGRed. That confuses me.
Again, PNGImageDecoder doesn't expose the resolution info, either,
although it has it. We may need to ask the Batik guys if they know what
this is about. This almost screams for a patch. :-)


On 12.08.2005 10:56:18 Manuel Mall wrote:
> I was looking at issues related to images not being displayed with their 
> correct resolution. As far as I understand all image formats apart from 
> GIF (which defaults to 72dpi) do carry resolution information. However, 
> it only works for JPEG at the moment. I managed to fix it for BMP 
> images by reading / interpreting the appropriate header fields. TIFF 
> and PNG are more complicated as the information is buried in the file 
> so you actually have to load the image to get to the information. Both 
> TIFF and PNG are currently implemented using BatikImage. However, it 
> appears that the Batik decoder doesn't make the resolution information 
> available. At least its not set in BatikImage.loadImage() and I 
> couldn't find a field in the 
> org.apache.batik.ext.awt.image.rendered.CachableRed class which looks 
> like holding the x and y resolutions.
> Any one knows how to get to the resolution settings for the Batik 
> images?
> Thanks
> Manuel

Jeremias Maerki

Reply via email to