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):
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
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
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
Created attachment 268621 [details]
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,
-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]
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
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
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.