#405 convert: "-page" behaviour with "+append"ed gif frame

[Aleksey]

# gm convert -size 150x100 xc:red red.gif
# gm convert -size 50x100 xc:green green.gif
# gm convert -size 25x100 xc:blue blue.gif
# gm convert -delay 100 red.gif -page +40+0 +append green.gif blue.gif animation.gif
# gm identify animation.gif
animation.gif[0] GIF 150x100+0+0
animation.gif[1] GIF 75x100+60+0

The second frame of animation.gif has 60px offset instead of the expected 40px. I wonder if this behaviour is intended and if there is a better way of specifying the offsets of the "+append"ed subimages. Presumably, 60px = 40 / 50 * (50 + 25).

GraphicsMagick 1.3.18 2013-03-10 Q8
GraphicsMagick 1.3.25 2016-09-05 Q8

[Bob Friesenhahn]

The +append command is forming a new raster image (more similar to montage) and I don't see any support for page offsets in the algorithm. I think that your expectation for +append is incorrect. The default behavior of convert is to do what you intend with your "+append" statement. All of the listed input image files are included in the output sequence by default. If you remove the "+append" and use -page before each input file to indicate its offset, then you should achieve success.

[Bob Friesenhahn]

Closing due to improper use of command line options. Not a bug.

[Aleksey]

Sorry for not being clear; let me put it differently. ImageMagick equivalent of the above-mentioned one-liner is the following:

convert -delay 100 red.gif -page +40+0 \( green.gif blue.gif +append \) animation.gif

Although GraphicsMagick syntax differs, the result is exactly the same: in both cases the second frame has 60px offset, not 40px. ImageMagick team fixed the issue a few days ago with commit 03e41aabaf601d8fe1b6e65bfeccc485b7afbd84 (I believe), and the latest beta 7.0.4-1~beta20161224 is correctly offsetting the "appended" frame by 40px. Since symptoms appear to be similar, any chance that image.c fix could be applied to GraphicsMagick?