<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#c17">Comment # 17</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:tsdgeos@terra.es" title="Albert Astals Cid <tsdgeos@terra.es>"> Albert Astals Cid</a> <pre>(In reply to <a href="show_bug.cgi?id=30692#c16">comment #16</a>) > >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. I never suggested checking the for each object. I suggested that PSOutputDev::startPage generates the cropbox with the given box in the state > > 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. Yes I know what a crop box is for. > 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? Because to me the patch looks like a hack, yes, hacks work, but they are not proper fixes.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>