[poppler] Printing of certain PDF files does not work with "fit-to-page" because of wrong BoundingBox values in the PostScript

William Bader williambader at hotmail.com
Tue Oct 27 10:33:58 PDT 2015



> To: stefan.brandner at gmx.at; poppler at lists.freedesktop.org
> From: ajohnson at redneon.com
> Date: Tue, 27 Oct 2015 23:08:54 +1030
> Subject: Re: [poppler] Printing of certain PDF files does not work with "fit-to-page" because of wrong BoundingBox values in the PostScript
> 
> On 25/10/15 21:08, Stefan Brandner wrote:
> > I want to summarize how the problem appears when printing the file
> > Dirichlet.pdf with okular.
> > Find the file at: https://bugzilla.opensuse.org/attachment.cgi?id=616147
> > 
> > 1. with OpenSuse 13.1 and okular 4.11.2 the CUPS command was without the
> > fit-to-page option
> > following commands are executed:
> > pdftops Dirichlet.pdf
> > lpr Dirichlet.ps
> > The file was printed unscaled but centered and the printout was useful.
> > 
> > 2. with the actual OpenSuse 13.2 and okular 4.14.9 the CUPS command is
> > now with fit-to-page and then the file is shifted to the right with half
> > of the text cut
> > this can be reproduced with following commands:
> > pdftops Dirichlet.pdf
> > lpr -o fit-to-page Dirichlet.ps
> > This does not work since the BoundingBox values are incorrect.
> > See explanation at CUPS documentation:
> > http://www.cups.org/documentation.php/options.html
> 
> I'm not sure which application is enabling the fit-to-page or why it
> changed. The fit to page would be better performed in pdftops which
> already has this capability. The problem with performing a fit-to-page
> based on the PS output is the Adobe Document Structuring Conventions
> define the BoundingBox to be the smallest box that encloses all marks on
> the page.
> 
> A PS file with correctly calculated PageBoundingBox comments is likely
> have a different bounding box on each page depending on the content. If
> fit-to-page is applied based on the bounding box, each page will have a
> different scale factor applied. A blank page with just a page number at
> the bottom will be scaled up to fit the page number to the entire page.
> This is probably not what you want.
> 
> The fit-to-page feature relies on the fact that a lot of applications
> just set the bounding box to the page size since computing the ink
> extents of all marks on the page is not trivial.
> 
> If a future version of poppler tightened up the PageBoundingBox to make
> it more correct you may find this workflow which relies on an incorrect
> interpretation of the BoundingBox comment may no longer work for you.


The problem is that the pdftops -paper option creates a PageBoundingBoxes that can point to empty space instead of to the image.

It is not that the PageBoundingBox is too large but that it is completely wrong.  pdftops always writes the PageBoundingBox as 0,0 to the width,height of the image, but if pdftops is run with -paper, it shifts the image up and to the right to center it on the page but it does not make a corresponding shift to the PageBoundingBox.

The issue is not setting the PageBoundingBox to cover the smallest rectangle necessary to cover the marks on the page.  An application that creates a document where a page has only a page number or a "this page intentionally left blank" notice will usually still write a normal page-sized crop box.  But if you have a document that was created for a small paper size like a note card and then you want to print it on A4, if you use pdftops -paper A4, pdftops will correctly center the note card pages on the A4 paper (and enlarge them if you use -expand), but it will leave the PageBoundingBox comments as a note card sized rectangle at the lower left corner, so viewers or applications that read the PageBoundingBox will look at empty space.

Regards, William


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20151027/611e2687/attachment.html>


More information about the poppler mailing list