Bug 393361 - Print quality poor from OpenOffice on Xerox Phaser printer with move from F7->F8 ghostscript
Summary: Print quality poor from OpenOffice on Xerox Phaser printer with move from F7-...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: ghostscript
Version: 8
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-20 22:40 UTC by Luke Ross
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-06-08 10:17:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
PS from OpenOffice (10.19 KB, application/postscript)
2007-11-25 23:39 UTC, Luke Ross
no flags Details
PS from evince (11.96 KB, application/postscript)
2007-11-25 23:41 UTC, Luke Ross
no flags Details
PDF from OpenOffice (4.78 KB, application/pdf)
2007-11-25 23:42 UTC, Luke Ross
no flags Details
vague guess (10.17 KB, application/postscript)
2007-11-26 08:51 UTC, Caolan McNamara
no flags Details
test-case document (8.95 KB, application/vnd.oasis.opendocument.text)
2007-11-27 09:18 UTC, Caolan McNamara
no flags Details
PS output from OO of attachment 269531 (12.97 KB, application/postscript)
2007-12-15 13:51 UTC, Luke Ross
no flags Details
PS output from Evince of attachment 269531 (via OO PDF) (10.48 KB, application/postscript)
2007-12-15 13:51 UTC, Luke Ross
no flags Details

Description Luke Ross 2007-11-20 22:40:23 UTC
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

Comment 1 Caolan McNamara 2007-11-20 22:57:38 UTC
sounds tricky to reproduce, whats the printer driver name for this printer ? 

Comment 2 Caolan McNamara 2007-11-21 11:00:15 UTC
a) can you print to file, as postscript, not as pdf, and check if that printed
from evince shows the problem as well.

Comment 3 Luke Ross 2007-11-21 23:41:46 UTC
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.

Comment 4 Luke Ross 2007-11-21 23:42:51 UTC
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.

Comment 5 Caolan McNamara 2007-11-22 08:08:21 UTC
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

Comment 6 Luke Ross 2007-11-25 23:39:34 UTC
Created attachment 268401 [details]
PS from OpenOffice

Comment 7 Luke Ross 2007-11-25 23:41:01 UTC
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.

Comment 8 Luke Ross 2007-11-25 23:42:11 UTC
Created attachment 268421 [details]
PDF from OpenOffice

Same original document as 268401; intermediate step of creating 268411.

Comment 9 Luke Ross 2007-11-25 23:43:08 UTC
Requested files attached. Printing 268401 results in blue smears, 268411 gives 
crisp text.

Comment 10 Caolan McNamara 2007-11-26 08:51:38 UTC
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

Comment 11 Luke Ross 2007-11-26 19:15:45 UTC
Yes, that fixes the problem. Attachment 268621 [details] prints crisply.

Comment 12 Caolan McNamara 2007-11-27 09:17:33 UTC
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

Comment 13 Caolan McNamara 2007-11-27 09:18:27 UTC
Created attachment 269531 [details]
test-case document

Comment 14 Caolan McNamara 2007-12-03 15:11:12 UTC
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.

Comment 15 Caolan McNamara 2007-12-14 14:00:41 UTC
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.

Comment 16 Luke Ross 2007-12-15 11:53:37 UTC
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.

Comment 17 Luke Ross 2007-12-15 13:51:22 UTC
Created attachment 289686 [details]
PS output from OO of attachment 269531 [details]

Comment 18 Luke Ross 2007-12-15 13:51:57 UTC
Created attachment 289687 [details]
PS output from Evince of attachment 269531 [details] (via OO PDF)

Comment 19 Caolan McNamara 2007-12-16 12:44:52 UTC
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.

Comment 20 Tim Waugh 2008-06-02 11:49:04 UTC
Needs re-testing with Fedora 9.

Please attach the PPD you are using for this printer (from /etc/cups/ppd/).  Thanks.

Comment 21 Luke Ross 2008-06-08 10:17:24 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.