Henning, sorry for not replying earlier -- I somehow believed the BTS
would Cc: me on everything, and didn't check the web interface until
today.
I tested your patch 533361.patch posted on the 19th, and of course it
fixed the crash (on amd64 and ppc) for both the test data attached to
the bug, and for my real data. Thanks for the quick response!
However, the resulting image still looks strange. I have attached yet
another example.
salix:/tmp/xcfbug% xcfinfo debian-logo.xcf
Version 0, 10x10 RGB color, 3 layers, compressed RLE
+ 48x48-18-18 RGB-alpha Normal L3
+ 48x48-18-18 RGB-alpha Normal L2
+ 48x48-18-18 RGB-alpha Normal L1
salix:/tmp/xcfbug% xcf2png -b white -C debian-logo.xcf L2 > L2.png
At first I expected L2.png to contain only the visible 10x10 center
part of layer L2. Then I reread the man page and realized that -C was
documented as the other way around.
What L2.png actually contains is the 10x10 canvas-visible part and
everything to the south and east of that. The rest is clipped, i.e.
filled -b white. I have other examples where *parts* of the layer
to the N and W of the canvas are retained, while others are filled
with the background color.
This *feels* like a bug. But I won't insist, since (a) it's not clear
which behavior a user would want in this case and (b) the
documentation for -C only talks about *cropping* to the layers, not
*expanding*.
Also, for me personally, this doesn't matter because now that xcf2pnm
no longer crashes, I can see that I do not want the -C effect. I want
my layers clipped to the canvas, just like xcf2pnm does by default.
many thanks,
/Jörgen
--
// Jörgen Grahn | mot du jour: TRIAL SEPARATION
\X/ <grahn@snipabacken.se> |
Attachment:
debian-logo.xcf
Description: application/xcf
Attachment:
L2.png
Description: PNG image
Attachment:
signature.asc
Description: Digital signature
