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).
