xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Noll <dan...@nuix.com>
Subject Re: Strange scaling of GIF images
Date Wed, 04 Apr 2007 23:58:55 GMT
Jeremias Maerki wrote:
> We defer the whole image loading to ImageIO in that case, so if ImageIO
> doesn't already handle the image offset, the code in FOP certainly
> doesn't. We'd have to write special code for GIF to handle the offset.
> With ImageIO you can access those values through the GIF Image Metadata
> Format which is described in the Javadocs if anyone wants to fix this.
> http://java.sun.com/j2se/1.4.2/docs/api/javax/imageio/metadata/doc-files/gif_metadata.html

Actually, I already contributed a patch to fix this bit, a day or two ago.

The information is in fact stored in the standard metadata so it isn't 
GIF-specific and will work for future image formats which happen to have 
the same feature.  Under each image's "Dimension" (for a GIF there is 
one per frame of the animation but we only care about the first one) 
there is a "HorizontalPixelOffset" and "VerticalPixelOffset".  Under the 
stream metadata's "Dimension" there is a "HorizontalScreenSize" and 
"VerticalScreenSize" which stores the true size of the image.

All my patch does at present is to mangle the bitmap array, but it can 
probably be improved.  I'm sure there is a bug or two in there as I 
haven't exhaustively tested it yet. :-)

> No, with the way FOP currently handles images. Your GIF images has a
> color table with 3 entries, two color being black. One of the blacks is
> used for the transparency mask, the other for black painting. Now, FOP
> currently converts the index bitmap into an (s)RGB image and later tries
> to find out which color is used for transparency. In your case black is
> used twice which is the real cause. In the PDF, the image object says
> that black is its transparency color but the PDF viewer has no way
> anymore to distinguish between black and transparent black. That's why
> you lose pixels. That's again something that should be resolved with the
> redesign of the image package because ImageIO properly returns the
> indexed color model. It's just a matter of preserving that.

I was thinking another workaround might be to somehow change the first 
colour in the palette to something else so that the collision doesn't 
occur.  I'm just hoping this won't involve opening the GIF, writing over 
the palette and saving it again. :-)

> Closing word: Don't use GIF. :-) And not just because of the patent
> problem (yes, I know it's expired).

The GIF is linked to from an HTML file which we happen to want to 
convert to PDF via XSL-FO.  So unless we manually convert all GIF files 
to PNG and change all the links from the FO file, it ain't gonna happen. :-)

With all this I have to wonder, do translucent PNGs work?


Daniel Noll

Nuix Pty Ltd
Suite 79, 89 Jones St, Ultimo NSW 2007, Australia    Ph: +61 2 9280 0699
Web: http://nuix.com/                               Fax: +61 2 9212 6902

This message is intended only for the named recipient. If you are not
the intended recipient you are notified that disclosing, copying,
distributing or taking any action in reliance on the contents of this
message or attachment is strictly prohibited.

To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message