Created attachment 27725 [details] test file with CropBox (cropped to 7"x9" centered on a US-letter MediaBox) [I reported this on the Debian bug system (bug 536646) but it doesn't seem to have been sent upstream. I encountered the problem with 0.10.6 as packaged by Debian, but the current pdftops.cc in the freedesktop.org git repo browser shows the same lines, so I suspect the problem is still there.] "pdftops book.pdf" produced an uncropped postscript file, whereas "pdftops -nocrop book.pdf" produced the cropped postscript file. The bounding boxes are (from pdfinfo): Page size: 504 x 648 pts MediaBox: 0.00 0.00 612.00 792.00 CropBox: 54.00 72.00 558.00 720.00 BleedBox: 54.00 72.00 558.00 720.00 TrimBox: 54.00 72.00 558.00 720.00 ArtBox: 54.00 72.00 558.00 720.00 (The file is created by ConTeXt/pdftex and has the following tex code to set the cropbox: \pdfpagesattr = {/CropBox [54 72 558 720]} ) The problem is (I think) fixed by the following patch: --- poppler-0.10.6.orig/utils/pdftops.cc +++ poppler-0.10.6/utils/pdftops.cc @@ -341,7 +341,7 @@ duplex); if (psOut->isOk()) { doc->displayPages(psOut, firstPage, lastPage, 72, 72, - 0, !noCrop, gFalse, gTrue); + 0, noCrop, !noCrop, gTrue); } else { delete psOut; exitCode = 2; Explanation: In the unpatched function call, !noCrop is passed in as useMediaBox into displayPages(), and gFalse is passed in as crop into displayPages(). But, from staring at the code, it seems that useMediaBox is the opposite of crop, so useMediaBox should be given noCrop and crop should be given !noCrop. Which is what the patched call does. The code feels fragile in having two variables that are synonyms (useMediaBox and noCrop) that turn into (via function calls) two variables that are antonyms (useMediaBox and crop) and have to be kept in sync. Why not just have one variable (e.g. useMediaBox)? Leaving that aside, I am not sure that the patch above is the whole fix. The last few lines of makeBox() (in poppler/Page.cc) are: } else if (useMediaBox) { *box = *mediaBox; } else { *box = *cropBox; *crop = gFalse; } The else-if clause looks okay, even if fragile, since *crop should already be passed in as gFalse (since useMediaBox is true). But the else clause looks suspicious. If useMediaBox is false, then the cropBox is being used, so why is *crop then set to false? Is it because the calling function doesn't want cropping on top of using the cropBox? I wasn't sure about what was going on there, so I left those lines alone, and just patched the call in pdftops.cc. With the patch, pdftops handles -nocrop correctly on book.pdf. Instead of attaching the huge book.pdf, I made a small test file testfile.pdf that I'm attaching.
Patch commited, thanks for the heads up
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.