I've probably assigned this to the wrong component (cups) but there are so many components (packages) which could be culprit I'll let someone else with more knowledge of the interplay between printing components assign this correctly. Starting with F-15 and now continuing with F-16 I've noticed a dramatic decrease in print quality on my high-end laser printer (Brother MFC-9840CDW). It is especially apparent with text. The best way to describe what I'm seeing is it appears as if the text was rendered as an image and that image was then scaled with a poor quality image scaler. Glyphs have pixel dropouts and glyph strokes have inconsistent widths, etc. I notice this with with a variety of print sources, PDF, Firefox, etc. At first I wasn't sure if it was the content or something in the printing system so I went to a Windows machine connected to the same printer and printed the same document, it rendered beautifully. So it seems to be something in Fedora printing subsystem and it seems to have appeared first in F-15. I don't recall having any print quality issues with the same printer in F-14 and lower. I have no idea if how apps render their printing has changed, if it's an issue with the printing language (assuming it gets converted to ghostscript) or with a device specific driver. I could imagine any one of these could be at fault. Let me know if I can provide any more information. I could attach a scanned image illustrating the rendering artefacts. Sorry for being somewhat vague, this isn't the best bug report.
It would be useful if you could attach an output from printing troubleshooter. https://fedoraproject.org/wiki/Printing/Debugging#Printing_troubleshooter
Created attachment 534811 [details] troubleshoot.txt output of Cups troubleshooting
Created attachment 534812 [details] Printed on F-16 Printed from Firefox on F-16
Created attachment 534813 [details] Printed on Windows XP Printed with Firefox on Windows XP, same web page. Notice the poor font rendering on F-16 when compared to the same application and document on Windows. The degradation in print quality first appeared in F-15, there was no noticeable differences in print quality between Fedora and Windows prior to F-15.
The troubleshoot.txt doesn't contain cups error_log. 1) cupsctl --debug-logging 2) systemctl restart cups.service 3) print the same file as before 4) attach the /var/log/cups/error_log Could you also try to create another printer queue using Brother MFC9840CDW Foomatic/Postscript or Brother MFC9840CDW Foomatic/pxlcolor driver ? Is the print quality influenced ?
Print quality is the same with these: Brother MFC9840CDW Foomatic/Postscript Brother MFC9840CDW Foomatic/pxlcolor
Created attachment 534833 [details] cups error log
Could this be a font selection issue? Suppose the font was not available, would another font be substituted which had problems scaling to the specified point size? It really looks like a scaling problem.
(In reply to comment #7) > Print quality is the same with these: > > Brother MFC9840CDW Foomatic/Postscript > Brother MFC9840CDW Foomatic/pxlcolor Another option would be some not-Foomatic Generic driver like 'Generic Postscript Printer' or Gutenprint driver like 'Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.7 Simplified' (In reply to comment #9) > Could this be a font selection issue? Suppose the font was not available, would > another font be substituted which had problems scaling to the specified point > size? It really looks like a scaling problem. Could you attach the original file you have been printing ?
The original file I was using as the example is this URL, printed with Firefox http://www.apachetutor.org/dev/request Not sure why I picked that file, just happened to be the one where my frustration overcame my inertia :-) The problem is seen with plenty of other print jobs. One of the problems with diagnosing the problem is there are so many components at play. Is it an issue with how Firefox generates printing? It it an issue with font selection? If it's a font issue is it occurring in the app, in the printing middleware or in printer driver? etc. etc. :-(
(In reply to comment #10) > Another option would be some not-Foomatic Generic driver like > 'Generic Postscript Printer' > or Gutenprint driver like > 'Generic PCL 6/PCL XL Printer - CUPS+Gutenprint v5.2.7 Simplified' Could you also try these two before we start narrowing the problem down ?
Created attachment 535449 [details] result of running pstops filter AFAICT Brother MFC-9840CDW is Postscript 3 compatible. So when the original file is postscript then only pstops filter should be involved. The 'Running filters by hand' [1] procedure could look like: 1) print from firefox to postscript (name e.g. test.ps) check that test.ps looks good 2) export PPD=/etc/cups/ppd/Brother-MFC-9840CDW.ppd /usr/lib/cups/filter/pstops 1 'me' '' 1 '' <test.ps >pstops.ps check that pstops.ps looks good 3) lpr -P Brother-9840 -o raw pstops.ps What do you think Tim ? [1] https://fedoraproject.org/wiki/Printing/Debugging#Running_filters_by_hand
Yes, looks like that should work.
John, could you try printing the pstops.ps file attached in comment #13 with 'lpr -P Brother-9840 -o raw pstops.ps' ?
re comment #15, The attached pstops.ps file printed normally with good font rendering.
I have a theory, perhaps I'm going out on a limb, but humour me for a moment. Suppose the library preparing the page to print generated a list of fonts necessary for the page and then asked the question "does the target printer have the necessary fonts?". If it does I'll send "raw" printing commands to the printer (e.g. set font, render string). Otherwise since the printer can't handle the font requirements I'll fallback to a software emulation whereby I use a native rendering library to render the page as an image and then send the image to the printer. Is that plausible? It doesn't seem to me that Postscript (or any other command language on the printer) is the one rendering the text. Part of my problem is I don't know how Linux applications print. I presume they use the same graphics library (e.g. GTK, pango, etc.) they use for screen presentation but in "print mode" and allow the graphics library to decide how it will generate printer commands (perhaps even using an intermediate format in a manner similar to compilers??) I strongly suspect CUPS is not the culprit here, rather the printing subsystem is doing what it's told to do by someone earlier in the pipeline. But I just don't understand all the steps which occur between hitting "Print" in an application and what is finally sent to the printer.
(In reply to comment #13) > AFAICT Brother MFC-9840CDW is Postscript 3 compatible. > So when the original file is postscript then only pstops filter should be > involved. Actually according to the error_log the input file is not postscript but pdf so there's also pdftops involved. And in my case printing http://www.apachetutor.org/dev/request from firefox to pdf and running pdftops filter on the result creates quite ugly postscript (something similar as in comment #3) so the problem is I think in pdftops filter (which just calls /usr/bin/pdftops from poppler-utils).
re comment #18, that would seem to make sense. I say that because yesterday I printed a PDF from Evince and it exhibited the same poor font rendering. I would expect a PDF sent to a Postscript capable printer to be sent as mostly unaltered Postscript commands (because my understanding is PDF and Postscript share a tremendous amount). But it appears as if when we print PDF something is getting in there and modifying what should be straight Postscript commands to render text. How this also relates to why the problem is also seen when printing from Firefox is out of my league :-)
Ok, let's pass this around to somebody with better insight. Summary to Marek: When I print http://www.apachetutor.org/dev/request from Firefox to pdf (which looks good) and then run /usr/bin/pdftops on the result I get quite ugly (in my opinion) postscript file.
Hi, the problem here is that the page contains images with alpha channel. The convertor converts the page as a raster because of that. This was already reported here: https://bugzilla.redhat.com/show_bug.cgi?id=574118 and here: https://bugs.freedesktop.org/show_bug.cgi?id=21723 This is a bug which will probably last for quite some time because upstream says that he will probably never get to fix it. I will try to look at it at some point in future but not now. Regards Marek P.S.: As a workaround you can remove alpha channel from the images on the page you are trying to print. Or you can print the page to PDF and convert it manually with pdftops to PostScript specifying higher DPI manually (default is 300 dpi). This will produce big PostScript file.
re comment #21. I disagree this is a low priority issue. I can no longer print from Fedora because a large percentage of the print jobs are of such poor quality I have to throw the output into the recycle bin and go to a Windows box. Something changed recently which has exacerbated the problem significantly (perhaps transparency has been incorporated into more components?). Anyway, IMHO this really needs to get fixed sometime soon.
What is the status of getting this fixed? Fedora 17 is showing the exact same issues.
I'm still having serious print quality issues in Fedora. The problem was identified 6 months ago. 2 months ago I asked for the status of a fix. I heard nothing. I'd really like to know what's being done to get this problem fixed and what the scheduled date is for the fix to appear. Thank you.
Same printer (Brother MFC-9840CDW), same quality problems. Better with F-15, now very bad with F-17.
I would appreciate the courtesy of getting a reply to my query concerning the status of getting this resolved.
Add bug dependency references. As far as status, I don't believe anything has changed since comment #21 (Marek can update/clarify as needed, of course).
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.