xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Strange scaling of GIF images
Date Wed, 04 Apr 2007 20:13:15 GMT
First of all, let me say that I personally think that GIF shouldn't be
used anymore today. I'd convert the image to PNG and use that. :-)

On 29.03.2007 01:57:09 Daniel Noll wrote:
> Pascal Sancho wrote:
> > Hmm, I tried it on Photoshop, and I confirm that I loose black pixels while rendering
"for the Web".
> > Strange. Someone else have an idea?
> I already said there is no way to "loose" pixels. :-)

Right. The GIF itself seems to be ok.

> Photoshop and whatever FOP is using to load the GIF possibly have the 
> same issue.
> The GIF file in question is like this:
>    +-----------------------------+   -        |
>    |                             |   ^        v
>    |    +------------------+     |   |        -
>    |    |                  |     | image     data
>    |    |                  |     | height   height
>    |    +------------------+     |   |        -
>    |                             |   v        ^
>    +-----------------------------+   -        |
>    |<------- image width ------->|
>         |<-- data width -->|
> This is possible since with the GIF format if the image pixels don't 
> take up the entire width of the image, you don't have to store them.  In 
> this situation the width and height of the image data is stored 
> separately to the image width and height, and there is an X and Y offset 
>   also, to say where the data is offset.

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.

> Incidentally this feature is also used in GIF animations so that when 
> only a small part of the image changes, only that part of the image 
> needs to be stored.
> Creating an image of this type isn't too difficult either... in GIMP:
>    * Create a new image with a transparent background.
>    * Create a new layer with width and height smaller than the image.
>    * Draw something on the layer.
>    * Save as GIF.
> I suspect the loss of black is something different entirely, probably 
> related to the way GIFs do transparency.

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.

> Whatever's going on though, the toolkit seems to know how to load the 
> image correctly so maybe there is a way to force FOP to use that for 
> GIFs instead of ImageIO.

Currently doable only by hacking FOP source code. I will probably see to it
that the redesign includes more fine-grained control over which image
library is used.

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

Jeremias Maerki

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

View raw message