Red Hat Bugzilla – Bug 393361
Print quality poor from OpenOffice on Xerox Phaser printer with move from F7->F8 ghostscript
Last modified: 2008-08-02 19:40:37 EDT
Description of problem: Printing a document from OpenOffice.org to my Xerox 6100BD printer (similar to Samsung CLP-510) gives very poor quality output. The text is very blurry and smudged with a blue tinge, to the point of affecting readability. The appearance suggests that it is being anti-aliased to a low resolution, badly. The same document exported to PDF and then printed from other applications (eg. evince) prints with crisp sharp black text. Version-Release number of selected component (if applicable): openoffice.org-core-2.3.0-6.6.fc8 cups-1.3.4-2.fc8 How reproducible: Always
sounds tricky to reproduce, whats the printer driver name for this printer ?
a) can you print to file, as postscript, not as pdf, and check if that printed from evince shows the problem as well.
The printer driver is sadly a nasty binary one supplied by Xerox or Samsung (PPD + some binaries). It invokes Ghostscript to, I think, render to bitmap, which is then mangled and sent to the printer. The CUPS test page claims the PS engine is Ghostscript and the driver stops working if /usr/bin/gs goes away. I rendered a document to a PS file from OpenOffice and then sent the PS to the printer directly using lpr, and it printed with the horrible blue smudges. I then tried printing the PS file from evince, and the blue smudge is also there. I can attach the OO-generated PS if that would be useful.
Just to clarify, I've used the binary printer driver happily under FC4-FC7 and have printed from OO without problems until I upgraded to FC8.
Yeah do that, attach the sample output .ps from OOo. Now you also said you had no problems if it was exported to .pdf and then printed from evince, so attach the same document exported to .pdf, and then finally attach the output from evince if you open the .pdf from OOo in that, and use print to file as .ps. And finally see if reopening that evince-created .ps in evince and printing to the printer gives such a blue-tinged output
Created attachment 268401 [details] PS from OpenOffice
Created attachment 268411 [details] PS from evince This is the same document as attachment 268401 [details], printed to PDF from OpenOffice, loaded into evince and then printed from evince to a PS file.
Created attachment 268421 [details] PDF from OpenOffice Same original document as 268401; intermediate step of creating 268411.
Requested files attached. Printing 268401 results in blue smears, 268411 gives crisp text.
Created attachment 268621 [details] vague guess I wonder if I take attachment 268401 [details] and remove the explicit "set to black" directive to create this document if it now makes any difference when printed, i.e. -0 0 0 setrgbcolor
Yes, that fixes the problem. Attachment 268621 [details] prints crisply.
Ok, well that's very interesting, the line is just setrgbcolor 0 0 0, i.e. "use black", so I can only assume that the printer software has no optimization path for that explicitly asked for state when it sees a setcolor directive, and instead is separately printing the red, green and blue channels to form black and it's slightly mis-aligned or something, giving the blue edge. Given that the one-liner made a difference, I suggest that you file the problem against the Xerox driver if you can find the right place to do that. You could also experiment with the document I will attach which uses various text colours that give differing whole number setrgbcolor directives and see if any of the combinations also show a blurry edge with a component colour showing
Created attachment 269531 [details] test-case document
Any update on this, does the above testcase show similar problems, except with colours, not just black when printed from OOo ? I kind of expected to see the same problem with this colour sample as the original b&w one, except that in this case the same problem would exist regardless of what app the .ps or exported .pdf is printed with as the capacity for optimizing away the setrgbcolor when it is just black wouldn't exist which is the leading theory for why it happened with a .ps from OOo and not a .pdf from OOo.
I'll have to assume that the problem lies in the printer driver or the printer itself, and that the color issue is some misalignment of the component colors when combined to create black.
I've printed the test case from OO. Only the black line shows smudging; the other three colours are fine. Again, if exported as PDF and printed from evince all colours (including black) print correctly. I can attach the two PS again if useful. On a different note, if I downgrade to ghostscript-8.15.4-3.fc7.*.rpm, OO prints perfectly again. If I re-upgrade to the fc8 package, it starts smudging again.
Created attachment 289686 [details] PS output from OO of attachment 269531 [details]
Created attachment 289687 [details] PS output from Evince of attachment 269531 [details] (via OO PDF)
oh excellent, so changing the version of ghostscript from F7 to F8 triggers the problem, that might help figure this out. Lets give it to ghostscript to consider what might have changed to reveal the problem.
Needs re-testing with Fedora 9. Please attach the PPD you are using for this printer (from /etc/cups/ppd/). Thanks.
Sorry, I have recently switched to using the open-source Splix drivers (http://splix.ap2c.org/). These offers better print quality than the Xerox binary drivers and also work fine in combination with F8 and F9's ghostscripts.