<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#c18">Comment # 18</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>>I suggested that PSOutputDev::startPage generates the cropbox with the given box in the state I think that with the patch, the postscript clip is generated by calls in Gfx::Gfx() when Page::createGfx() calls new Gfx(). I agree that my patch is hacky. So I understand, you want to keep Gfx::Gfx() and have PSOutputDev::startPage() generate the clip line? Can startPage() use page->getCropBox() ? That would save passing it. Gfx::Gfx() calls out->startPage(pageNum, state); out->setDefaultCTM(state->getCTM()); before calling out->clip(state); so that the CTM is initialized before generating the clip. If PSOutputDev::startPage() sets up the clip, it would be generated before the CTM is initialized. Is that a problem? Since Page::createGfx() is generic to all output, while PSOutputDev::startPage() is specific to postscript, would moving the patch from createGfx() to startPage() mean other devices that wanted to crop to the cropbox would need to implement it in their own startPage()> William</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>