<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] add antialiasing to pdftops 0.28.1" href="https://bugs.freedesktop.org/show_bug.cgi?id=85934#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [PATCH] add antialiasing to pdftops 0.28.1" href="https://bugs.freedesktop.org/show_bug.cgi?id=85934">bug 85934</a> from <a class="email" href="mailto:williambader@hotmail.com" title="William Bader <williambader@hotmail.com>"> William Bader</a> <pre>Does this patch to pdftops have any chance of being accepted? The anti-aliasing code paths are well tested, so enabling anti-aliasing should be safe: GlobalParams.cc initializes antialias to gTrue, so pdftoppm has anti-aliasing enabled by default, and pdftocairo enables anti-aliasing for bitmapped output. The generated postscript should remain the same unless pdftops has to fall back to rasterizing the image, so normal ps output will be unaffected: PSOutputDev.cc uses the anti-alias flag only in checkPageSlice() when it needs to create a SplashOutputDev. Why does GlobalParams.cc initialize antialiasPrinting to gFalse? Is it for performance or memory issues or does enabling anti-aliasing have other side effects that produce bad postscript output? In my case, I am using pdftops to make an eps that is one of many images embedded on a postscript page, and then the page is both printed and converted to PDF for viewing over the internet. When pdftops rasterizes an eps, anti-aliasing makes text in that eps look better in the printed version of the complete document and much better when viewing the PDF version of the complete document.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>