<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [PATCH] pdftops does not crop" href="https://bugs.freedesktop.org/show_bug.cgi?id=30692#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [PATCH] pdftops does not crop" href="https://bugs.freedesktop.org/show_bug.cgi?id=30692">bug 30692</a> from <a class="email" href="mailto:williambader@hotmail.com" title="William Bader <williambader@hotmail.com>"> William Bader</a> <pre>>The issue as I see it is that you give the PSOutputDev a box, and it allows commands outside that box to be rendered, that is wrong and shall be fixed at the PSOutputDev level, not somewhere else. With the patch, pdftops crops by generating a single crop box in postscript at the beginning of the page. I think that xpdf (which works) does that also. Checking the crop box inside poppler before rendering each object could be expensive, and it could be tricky with text that was part inside and part outside. In theory, a pdf should not attempt to draw much outside the crop box other than a small amount of descriptive information (as in the example pdf that I attached) or registration marks for printing. The example pdf has an image of an ad that was intended to be placed on a newspaper page. The crop box marks the part of the image that should appear on the page. The objects outside the crop box are for proofing the image as a stand-alone item. I have the same problem as you that I have very little time. If you can tell me exactly where poppler should make the crop test, I can try it. The patch has been working for me for years, and one of the libreoffice people said that it worked for them also, and it is only a very small change. Isn't a bigger change more likely risk side-effects that could take a while to discover?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>