#253 convert pdf output page is the wrong size with -geometry "100%"

[mkf8]

Description:
When using -geometry '100%' (or omitting the -geometry parameter), it is possible for PDF output to have an improperly sized page. Output is correct when using 99% or 101% (or other non-exact scaling). It is also correct if the input is a gif.

Steps:
1 Make 100DPI source files (jpg, png, bmp, gif) at size 2848x4288
2 Run convert command:
gm convert img-conf.jpg -compress jpeg -density 72 -units PixelsPerInch -auto-orient -geometry '100%' conf-out.pdf
3 Open conf-out.pdf in Document Viewer or Acrobat or something that can show the page size (check the properties or document info box)

Expected result:
At 72 DPI, conf-out.pdf should be output at 3956x5956 for a size of 39.56 × 59.56 inch

Actual result:
gm convert outputs with a default conf-out.pdf size is 7.31 × 11.00 inch

Notes:
Some debugging uncovered that in pdf.c, WritePDFImage calls GetMagickGeometry with page_geometry as a default "612x792>", instead of "2848x4288+0+0" when it works. Also, in WritePDFImage we ended up with a CropBox buffer of "/CropBox [0 0 526 792]" instead of the desired "/CropBox [0 0 2848 4288]"

With non-100% scaling, it actually seems to work properly. Repeating the command with -geometry '99.9%' results in the correct size, 39.51 × 59.50 inch. Also, with -geometry "101%", the pdf is sized correctly at 39.94 × 60.15 inch. There's just the strange discontinuity at 100%. Also, if (and seemingly, only if) the input is a .gif file, then it will actually work at 100%, but not for jpg, png, and bmp.

Approx lines pdf.c:819-827 show where the erroneous default page_geometry comes from, and that the mechanism is 0 values in image->page.width and height. it is suspicious that ReadGIFImage in gif.c sets those values, but ReadPNGImage and ReadJPEGImage, etc. do not.

Also of interest are these approx lines in command.c:9788-9790 where the geometry section of MogrifyImage avoids calling ZoomImage for 100% sizing of png, jpeg, and bmp. This part branches on (image)->columns and rows rather than (image)->page.width and height, which are the fields that are actually used later on.

Version:
default branch tip from 2013-10-26
Ubuntu 12.04

[Bob Friesenhahn]

I think that there are some red herrings in here. It does seem that there is an inconsistency at 100% but I don't think that it is due to default image->page.width and height. GIF does not support the notion of resolution while the other tested formats do so it is different than the others. The -page option can be used to specify the desired Postscript/PDF page size and the usage is different than for GIF.

[mkf8]

Thanks for the clarification about GIF and the quick response!

The MogrifyImage() logic to prevent calling ZoomImage() for 100% scaling seems desirable, but it also seems like ZoomImage() is the only way image->page.width and height are being set for PNGs and JPGs. Do you think the image->page.width and height fields should be set properly elsewhere (whether in ReadXImage() functions or not), or that the WritePDFImage() logic in pdf.c should depend on something other than these fields?

In my case, I'd actually like to specify a * parameter in my input, and have each page of the PDF size according to each input file's dimensions/resolution. Ie. same situation, but multiple pages. So while I could manually pre-compute dimensions for -page when converting a single image, it's a bit onerous, and wouldn't generalize to multiple pages. Maybe there's another command-line workaround?

[mkf8]

update to my own comment: seems like specifying -extent '100%' serves as a workaround

[Bob Friesenhahn]

Thanks for reporting this bug. It turns out that Image page width and height were being initialized to the image dimensions under some conditions, but not by default. With Mercurial changeset 13962:d1de19ce8b36 the Image page width and height is defaulted to the image dimensions by default if it has not already been set. This should resolve the apparent bug in the PDF writer.