Bug 42028

Summary: Incorrect rendering of GIF images
Product: Fop - Now in Jira Reporter: Trejkaz (pen name) <trejkaz>
Component: imagesAssignee: fop-dev
Status: NEW ---    
Severity: normal    
Priority: P3    
Version: all   
Target Milestone: ---   
Hardware: Other   
OS: other   
Attachments: gif-scaling-bug.zip
Proposed patch

Description Trejkaz (pen name) 2007-04-02 22:22:22 UTC
Attached zip file contains an example with a single GIF, which exhibits two
  1. the GIF is scaled in a strange fashion, and 
  2. the black lines are lost.
Comment 1 Trejkaz (pen name) 2007-04-02 22:22:48 UTC
Created attachment 19896 [details]
Comment 2 Trejkaz (pen name) 2007-04-02 22:23:50 UTC
I may have a fix for #1 -- ImageIOImage was using the image data array to
determine the image size, which isn't necessarily the case for GIF.
Comment 3 Trejkaz (pen name) 2007-04-02 22:39:26 UTC
Created attachment 19897 [details]
Proposed patch

Attached patch uses the ImageIO metadata DOM to obtain the width and height, as
well as the horizontal and vertical pixel offset.  When building the bitmap
array, offsets the stored image pixels.

I'm not sure how to solve problem #2 though.
Comment 4 Trejkaz (pen name) 2007-04-03 00:06:43 UTC
Some investigation of #2, inside ImageIOImage#loadBitmap:

alphas = { 0, 255, 255, 255 }
reds   = { 0,   0, 187,   1 }
greens = { 0,   0, 224,   2 }
blues  = { 0,   0, 227,   3 }

The first palette colour is the transparent colour, which is black.  The second
colour, which is *not* transparent, also happens to be black.

FOP assumes that the transparent colour doesn't occur anywhere in the image, yet
in this situation it does.

Maybe it would be possible to pick an RGB combo which doesn't exist in the
image, recolour all the transparent pixels to that colour and then set that as
the transparentColor field.  That way it wouldn't clash with real drawn pixels
which happened to have the same colour.
Comment 5 Glenn Adams 2012-04-07 01:41:43 UTC
resetting P2 open bugs to P3 pending further review