FS#32968 - [ghostscript?] cups-pdf produces ugly pdfs through its pixelated font
Attached to Project:
Arch Linux
Opened by Kasi (popsch) - Wednesday, 05 December 2012, 06:10 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 29 March 2013, 10:43 GMT
Opened by Kasi (popsch) - Wednesday, 05 December 2012, 06:10 GMT
Last edited by Andreas Radke (AndyRTR) - Friday, 29 March 2013, 10:43 GMT
|
Details
I have exactly this problem:
http://www.qc4blog.com/?p=770 The outlined fix worked for me. Now I wonder how ubuntu does it, because it seems the defect still exists upstream. |
This task depends upon
Please attach all cups.logs with debug mode.
If it's caused by a bug in pdf2ps - the filter is part of ghostscript pkg. You may want to get in contact with Till Kampeter being the printer guru and responsible for most upstream developement.
I have some really old pdfs I have printed with cups-pdf that do not show this problem, the differences I see are:
- fonts are embedded in the good pdf
- the producer and creator fields of the pdfs are different. The good pdf has "Producer: GPL Ghostscript 8.71" and "Creator: cairo 1.8.10 (http://cairographics.org)", the bad pdf has "Producer: GPL Ghostscript 9.06" and "Creator: GPL Ghostscript 906 (ps2write)".
How to reproduce (to get a bad pdf):
Open any page (any page of the cups web interface will do) with a browser (chomium will do), print it to the virtual printer associated with cups-pdf.
A good pdf would be similar to what can be obtained by using Print -> Print to file with any program that supports printing to pdf directly.
Output of pacman -Q cups cups-pdf ghostscript cups-pdf poppler:
cups 1.6.1-6
cups-pdf 2.6.1-1
ghostscript 9.06-1
cups-pdf 2.6.1-1
poppler 0.20.5-1
(1) cups-pdf seems to be the one to blame since printing to pdf with cups directly works as expected (jut not as convenient and secure as with cups-pdf).
In the emails we have exchanged, it was determined that cups-pdf works as intended if called manually/directly and fed a postscript file. I the last email I received I was told this:
"I just wanted to let you know I am still on it but could not find the culprit yet. I think I will set up a number of virtual machines with different distributions so I can figure out when the error happens and when it does not."
Until the problem is found and fixed, I have found 2 workarounds, none of which is ideal though.
1) Change the default postscript printing renderer, this will make cups-pdf work a little better, at least type 1 fonts will get embedded but text might not be searchable. Do the change with:
lpadmin -p <CUPS-PDF printer name> -o pdftops-renderer-default=pdftops
2) Use a different way to print to pdf, this one is cumbersome to use and might not be safe in a multiuser environment.
To use this, edit cups configuration file and add a line with 'FileDevice Yes', then restart cups.
Add a new printer, select any option from the "Other Network Printers". In the "Connection" field input "file:/var/spool/pdfoutput.pdf".
In the "Make" list select "Generic" and in the "Model" list select "Generic PDF Printer (en)".
You can now print to the new printer and get a pdf with type 1 fonts embedded. However the pdf will get overwritten every time you print a new pdf, also you will have to change the permissions on the file so everyone can read it, otherwise only root can read the file.
Let me know if I can be of any use by also having the same bug, perhaps I can provide info to upstream if they need it.
Either way, thanks much for chasing things down.
https://bugs.linuxfoundation.org/ - for cups-filters choose product "OpenPrinting", component "cups-filters"
for cups-pdf ping the upstream dev.