Bug 22784 - pdftops inverts the meaning of the -nocrop option
Summary: pdftops inverts the meaning of the -nocrop option
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-15 08:47 UTC by Sanjoy Mahajan
Modified: 2009-07-27 14:22 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test file with CropBox (cropped to 7"x9" centered on a US-letter MediaBox) (5.05 KB, application/pdf)
2009-07-15 08:47 UTC, Sanjoy Mahajan
Details

Description Sanjoy Mahajan 2009-07-15 08:47:40 UTC
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.
Comment 1 Albert Astals Cid 2009-07-27 14:22:34 UTC
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.