[Pkg-gmagick-im-team] Bug#1115346: ImageMagick rotation introduces caNv without being asked and GIMP copies caNv verbatim even if the size of the image changes

[Peter Müller]

It turned out that in my workflows, rotation by a nontrivial angle (e.g., strictly between 0 and 90) introduces a caNv chunk, and a subsequent conversion to PDF (but not to many other formats, say, JPG, JPEG2000, GIF, or TIFF) exposes the havoc.  E.g., grab https://www.debian.org/logos/openlogo-100.png and run

     magick openlogo-100.png -rotate 10 openlogo-100.rotated.png
     magick openlogo-100.rotated.png openlogo-100.rotated.pdf

In openlogo-100.rotated.pdf, the stuff in the bottom left is cut away, and white margins on the top and right are added.

The issue is exacerbated by the fact that if you open file.rotated.png in GIMP, crop the image (Shift+C) to a smaller size, resize the layers to the size of the image, and export the result, you get exactly the same caNv chunk in the exported PNG. The tools don't warn you about the contamination during all the operations with magick and GIMP (and probably more tools, as the chunk is safe to copy by the PNG specification). You only notice the mayhem quite late, when viewing the final PDF—if you're lucky.

As caNv is nonstandard, I suggest both skipping this poison during rotation and ignoring it during conversion to PDF by default (i.e., unless an extra switch or extra switches requests it).