On Thu 13 Jun 2013 at 17:22:20 +0800, 王晓林 wrote: [Snipped: A very useful account of a testing procedure]
> In a short word, all the PS in /var/spool/cups look very good; all the PDF > in ~/PDF look ugly. In the attachment, you can find > > 1. d00107-001, the PS file in /var/spool/cups > 2. d00107-001.pdf, ps2pdf output > 3. d00109-001.pdf, the error_log This error_log (and the other one posted) show the PostScript file being filtered as follows: PS in ---> pstopdf ---> pdftopdf ---> pdftops ---> then to cups-pdf This is the PDF centric work flow. In principle there is nothing wrong with this chain being used. In practice an exception is made when the input is PostScript and the output is being sent to a PostScript printer. The *cupsfilter line in cups-pdf's PPD is commented out, so it is seen as a PostScript printer. The filter chain is then: PS in ---> pstops---> then to cups-pdf and this filtering sequence is used if /usr/share/cups/mime/mime.convs contains application/postscript application/vnd.cups-postscript 65 pstops In cups 1.5.x the cost factor for pstops is indeed 65. In cups 1.6.2 the cost factor is 66 (bug?). The immediate solution to your 'bad' PDFs is to alter '66' to '65'. However, I do not think this addresses the fundamental bug. Xiaolin, would you please do some more testing? Basically, would you comment on the appearance of the PDFs when text and PDF documents are sent to cups-pdf with cost factors of 65 and 66? Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
