<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'><div>Thanks, I think that your example-all.pdf at <a href="http://www.pahlx.de/poppler/" target="_blank" style="font-size: 12pt;">http://www.pahlx.de/poppler/</a> is a good test.</div><div><br class="Apple-interchange-newline">Should that pdf and the rest of this discussion move to the bug report at <a href="https://bugs.freedesktop.org/show_bug.cgi?id=87161" target="_blank" class="c_nobdr t_prs" style="font-size: 12pt;">https://bugs.freedesktop.org/show_bug.cgi?id=87161</a> ?</div><div><br></div><div>When I run "pdftops -paper A4 example-all.pdf" with the original and patched pdftops and then open the pages in "gv", in the original version, if I change the paper size pull-down from A4 to BBox, I see only part of the image or nothing at all, since the original version always writes a %%PageBoundingBox with the lower left at the origin, and pdftops translates centered images away from the origin. The patched version shows all of the pages correctly.</div><div><br></div><div>I think that your changes make sense. The unpatched version always writes "%%PageBoundingBox: 0 0 {0:d} {1:d}\n" which I think is not correct.</div><div><br></div><div>When I follow the code in PSOutputDev::startPage(), in the section with the comment "center", your patches put the centering offset in pbbtx and pbbty instead of tx and ty, but then add them into tx and ty, and in the end tx and ty (used for the postscript "translate") remain the same as in the unpatched version. So at most, your patches could affect the %%PageBoundingBox comment but not any of the postscript.</div><div><br></div><div>Since the current %%PageBoundingBox is incorrect, I think that makes your patches low risk because the only thing that they have a chance of breaking is already broken.</div><div><br></div><div>In the lines that print the %%PageBoundingBox, it rounds the URX and URY, but I think that they should always go to the next higher integer to ensure that they cover every mark. For example, if the width is 100.1, I think that the URX should be 101 because an URX of 100 would miss the marks >100 and <= 100.1.</div><div><div><br></div><div>writePSFmt("%%PageBoundingBox: {0:d} {1:d} {2:d} {3:d}\n", <span style="font-size: 12pt;">int(pbbtx), </span><span style="font-size: 12pt;">int(pbbty), </span><span style="font-size: 12pt;">int(width * xScale + pbbtx + 0.5),</span><span style="font-size: 12pt;"> int(height * yScale + pbbty + 0.5));</span></div></div><div><br></div><div><br></div><div>The only thing that I noticed, which is unrelated to your patches, is under the comment "deal with odd bounding boxes or clipping" where it sets "tx -= xScale * x1". At that point, tx and xScale are post-rotation but x1 is pre-rotation.</div><div><br></div><div>Regards,</div><div>William</div><div><br></div><div><div>> From: Bugzilla@pahlx.de<br>> To: williambader@hotmail.com; poppler@lists.freedesktop.org<br>> CC: ajohnson@redneon.com<br>> Subject: Re: [poppler] Printing of certain PDF files does not work with "fit-to-page" because of wrong BoundingBox values in the PostScript<br>> Date: Sun, 25 Oct 2015 10:22:25 +0100<br>> <br>> That seems to be a problem of your email client or editor. All the files were <br>> created with Linux tools. I checked the attachement I sent. The line ending is <br>> always LF not CR/LF.<br>> <br>> Maybe the PDP11 compiler was inefficient in compiling switch statements. To my <br>> understanding - and that is what I teach my students - code should be as <br>> understandable as possible because it's wirtten once but read many times. It's <br>> up to the compiler to do the optimization. But if it consensus that switch-<br>> statement should not be used in the poppler project for any reason, I can <br>> alter the patch in this direction.<br>> <br>> I created some more PDF examples now. example-big is a box bigger than A4 page <br>> size. example-small is a box smaller than A4 pages size. I rotated those PDF <br>> files using pdftk in all 4 directions. Then I converted the files with pdftops <br>> to postscript A4 paper (-paper A4) and unscaled (no options). example-all is <br>> the concatination (pdftk) of all example PDF files in to one multiple page file <br>> with different orientations. <br>> <br>> As these are a lot of files I did not attach them to this mail. Instead you can <br>> download these examples from my website at http://www.pahlx.de/poppler/<br>> <br>> Just look at the example-all-a4.ps using gv selecting BBox and you can see <br>> that all PageBoundingBoxes are wrong because the are not translated to the <br>> output media.<br>> <br>> Cheers,<br>> <br>> Martin Pahl <br>> <br>> Am Samstag, 24. Oktober 2015, 23:27:49 schrieb William Bader:<br>> > I noticed that the files were all in MSDOS format with CR-LF line endings,<br>> > which corrupted the PDF, but I could fix it in emacs. Do you have sample<br>> > files in all four orientations? I think that it would be good to exercise<br>> > all of the code. Does the problem happen only when the -paper option is<br>> > used because pdftops shifts the image but (without your patch) does not<br>> > make the corresponding changes to the bounding box? I noticed that you<br>> > changed a sequence "if (rotate == 0) { } else if (rotate == 90) {} etc"<br>> > into a "switch (rotate) { case 0: ... case 90: ... case 180: ... etc }". I<br>> > learned C in the old days on a pdp11 where a switch like that could<br>> > generate a huge jump table. Is that still an issue? Regards,William<br>> > <br>> > From: Bugzilla@pahlx.de<br>> > To: poppler@lists.freedesktop.org; ajohnson@redneon.com<br>> > Date: Sat, 24 Oct 2015 18:28:07 +0200<br>> > Subject: Re: [poppler] Printing of certain PDF files does not work<br>> > with "fit-to-page" because of wrong BoundingBox values in the PostScript<br>> > <br>> > Attached you find an example:<br>> > <br>> > example.pdf: a box generated with xfig 321mm x 106mm<br>> > <br>> > example.ps generated with pdftops -paper A4 example.pdf<br>> > example.ps:%%PageBoundingBox: 0 0 302 912<br>> > <br>> > example-patched.ps generated with pdftops -paper A4 example.pdf, but with<br>> > the patched version.<br>> > example-patched.ps:%%PageBoundingBox: 158 0 437 842<br>> > <br>> > You can view the postscript files with gv and select BBox. It's obvious that<br>> > the unpatched PageBoundingBox is totally wrong, because source coordinates<br>> > are used. The PageBoundingBox is bigger then the A4 paper format. It's just<br>> > the size of the original box (302 /72 dpi * 25,4mm = 106,5mm; 912/72 dpi *<br>> > 25,4mm = 321,73mm). But it must be the box scaled down to A4 and shifted to<br>> > the center.<br>> > <br>> > Hope this example helps.<br>> > <br>> > Regards,<br>> > <br>> > Martin Pahl<br>> > <br>> > Am Freitag, 23. Oktober 2015, 21:46:02 schrieb Adrian Johnson:<br>> > > On 21/10/15 03:32, Stefan Brandner wrote:<br>> > > > ------------------------------------------------------------------------<br>> > > > <br>> > > > I am using the patch now for several month and I can prove it is working<br>> > > > fine. So if the code quality is ok for you Albert why not pushing it?<br>> > > > <br>> > > > Regards<br>> > > > Stefan Brandner<br>> > > <br>> > > I'll take a look at the patch sometime in the next week. It would help<br>> > > <br>> > > if you:<br>> > > - attach a PDF that reproduces the bug<br>> > > - list the pdftops options you are using<br>> > > - list the bounding box output you are getting and what you think<br>> > > <br>> > > it should be.<br>> > > > <br>> > > > El Dijous, 7 de maig de 2015, a les 09:34:09, Martin Pahl va escriure:<br>> > > >>/Hi, />//>/I sent patches to fix the bug:<br>> > > >>/>//>/https://bugs.freedesktop.org/show_bug.cgi?id=87161 />//>/Those<br>> > > >>patches were automatically sent to poppler-bugs mailing list. But>><br>> > > >><br>> > > > as I />/see no reaction to my patch submission (poppler-bugs seems to be<br>> > > > a<br>> > > > />/mailinglist without human interaction) I just want to ask, what is<br>> > > > the<br>> > > > />/right way to submit patches. / It is.<br>> > > > <br>> > > > What we need is more people with time to review patches.<br>> > > > <br>> > > > Cheers,<br>> > > > <br>> > > > Albert<br>> > > >><br>> > > >>/By the way this bug is really annoying as it makes all PDF viewers<br>> > > >>using<br>> > > >>/>/poppler useless for printing documents that do not have the page size<br>> > > >>of>><br>> > > >><br>> > > > the />/output device (e.g. printer). On the other hand acroread is not<br>> > > > an<br>> > > > />/alternative anymore as Adobe has discontinued support for Linux.<br>> > > > />//>/Regards, />//>/Martin Pahl /<br>> > > > <br>> > > > <br>> > > > <br>> > > > _______________________________________________<br>> > > > poppler mailing list<br>> > > > poppler@lists.freedesktop.org<br>> > > > http://lists.freedesktop.org/mailman/listinfo/poppler<br>> > > <br>> > > _______________________________________________<br>> > > poppler mailing list<br>> > > poppler@lists.freedesktop.org<br>> > > http://lists.freedesktop.org/mailman/listinfo/poppler<br>> > <br>> > _______________________________________________<br>> > poppler mailing list<br>> > poppler@lists.freedesktop.org<br>> > http://lists.freedesktop.org/mailman/listinfo/poppler<br>> <br></div></div> </div></body> </html>