Original dimensions are remembered when cropping => issues with PDF output

[Skippy]

Hi,

Maybe it is the expected behaviour, but considering a 200x200 PNG image with a 100 px border — that makes it 400x400.

We have :

Code: Select all

$ convert input.png -trim output.png
$ identify output.png
output.png PNG 200x200 400x400+100+100 8-bit sRGB 12.9KB 0.000u 0:00.000

How comes it isn't 200x200 200x200+0+0 ?

This doesn't seem to be much an issue most of the time, since the geometry information seems discarded by most programs.

However, it is not always discarded by ImageMagick itself. Namely :

Code: Select all

$ convert output.png issue.pdf
$ identify issue.pdf
issue.pdf PDF 400x400 400x400+0+0 16-bit Bilevel Gray 20.1KB 0.000u 0:00.000

Note that direct conversion also fails (use-cropbox or use-trimbox options doesn't seem to help) :

Code: Select all

$ convert input.png -trim failed.pdf
$ identify failed.pdf 
failed.pdf PDF 400x400 400x400+0+0 16-bit Bilevel Gray 20.1KB 0.000u 0:00.000

In both cases the PDF image is identical to the original (non-cropped) image. Had we cropped to a reduced area, the image would be different but the dimensions of the PDF would still be the same, with a 100 px border.

This is quite misleading when you are dealing with images with borders larger than the illustration, and the PDF output is always blank/empty…

I'm running ImageMagick 6.9.2.7-1 from Fedora 23.

[snibgo]

Use "+repage" after "-trim".

[Skippy]

Thanks ! I can't understand how I could have missed this information from the documentation :

Always use "+repage" after any 'crop' like operation.
Unless you actually need to preserve that info.

[glennrp]

In a cropped PNG image, the original dimensions are stored in the standard "oFFs" chunk and the nonstandard "vpAg" chunk. The "+repage" option instructs ImageMagick to discard those chunks while writing the PNG output file.