Thanks for your report. "Critical: causes serious data loss, or introduces a security hole on systems where you install the package."
Did the above issue introduce a security hole or cause serious data loss? I seriously doubt that it did. Thus, I'm bringing severity down to important. PS: I would tremendously appreciate it if you filed a bug against gs-esp for this issue, as this seems to be where the real problem is. Thanks! On 5/2/07, Christopher Zimmermann <[EMAIL PROTECTED]> wrote:
Package: cups-pdf Version: 2.4.2-3 Severity: critical Tags: patch Justification: breaks the whole system Hi! When printing certain files via cups-pdf, gs runs forever using all cpu and slowly eating all memory. In consequence the system becomes unresponsive after a few seconds and therefore unusable. If you think this bug is not critical, please tell me, so I know better next time. A typical example in our environment would be a MS Excel user printing to the cups-pdf printer using dim borderlines. If you'd like an example .ps file I can provide one. Actually this seems to be a bug in gs-esp, but since I managed to fix it in cups-pdf, I file it against cups-pdf. I could fix it by adding -c .setpdfwrite in the config: GSCall %s -q -dCompatibilityLevel=%s -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="%s" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f %s I removed the -c save pop, since /usr/share/doc/gs-esp/Use.htm [Improving Performance] suggests that it is not needed. I don't really understand why this fix works and probably this has to be fixed in gs, too. But the default of gs should be changed anyway as far as I understand the -c .setpdfwrite option. I don't think it is the same bug as #267423 since for me gs never finishes. Kind Regards, Christopher Zimmermann
-- Martin-Éric Racine http://q-funk.iki.fi
