Attached zip file contains an example with a single GIF, which exhibits two problems: 1. the GIF is scaled in a strange fashion, and 2. the black lines are lost.
Created attachment 19896 [details] gif-scaling-bug.zip
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.
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.
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.
resetting P2 open bugs to P3 pending further review