[Poppler-bugs] [Bug 22784] New: pdftops inverts the meaning of the -nocrop option

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=22784

           Summary: pdftops inverts the meaning of the -nocrop option
           Product: poppler
           Version: unspecified
          Platform: All
               URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536646
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: general
        AssignedTo: poppler-bugs at lists.freedesktop.org
        ReportedBy: sanjoy at mit.edu


Created an attachment (id=27725)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=27725)
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.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.