233345 - [ps] letters widely spaced and/or overlapping when printing using default postscript printer

Status: RESOLVED DUPLICATE of bug 109970

(Core :: Printing: Output, defect)

Description

[JP]

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-0.backports.org.1

When printing using the default postscript printer, letters and words are widely
spaced and/or overlapping.  The html link supplied shows a print preview which
roughly reflects the problem (although individual characters are much more
widely spaced on paper).

Text looks fine in the browser (though some problems in Print Preview). 
Printing works fine in other applications.  I have had this problem with both 
the backported Debian version of Mozilla (1.6) and the Debian unstable version
(also 1.6).

Changing the print command to

mozprintfile=`tempfile`; cat > $mozprintfile && gs -sDEVICE=ljet4
-sOutputFile=\|lpr -dNOPAUSE $mozprintfile && rm $mozprintfile

largely tidies up the problem, for reasons I cannot explain.

I am using CUPS (not XPrint).

I did wonder if this might be a font problem, since in doing some playing
around, I discovered Japanese pages would print nicely (my system is configured
us-en, but I just happened to try printing yahoo.co.jp and everything was spaced
nicely).  But I'm not sure.

Reproducible: Always
Steps to Reproduce:
1. View any page (e.g. bugzilla.mozilla.org)
2. Print using Default Postscript printer with default command
Actual Results:  
Letters print with wide spaces in between them, and some words/letters overlap.
 The text will not fit on the page properly.

Expected Results:  
The text should have been printed as it appeared on the screen, in the browser
window.

See http://www.geocities.com/jumbophut/snapshot2.jpg for a rough idea of the
behaviour of printing (as noted above, the hard copy has much larger spaces
between letters as well as overlaps).

Comment 1

[Andrew Schultz]

> See http://www.geocities.com/jumbophut/snapshot2.jpg..

"This page is not available"

What URL are you trying to print?

Comment 2

[JP]

Attachment: Print preview of google page (shows problem, but not as bad as on paper)

I have added this attachment because the link to geocities is not working.  I
need to stress that Print Preview, while showing some rendering problems, does
not have the more severe problem seen on actual printed output.  In printed
output, the letters are much more widely spaced.

Comment 3

[Kenneth Herron]

Using recent CVS builds on solaris and linux, I can reproduce the problem in
print preview but not in an actual printout.

In print preview, mozilla appears to be getting the text width calculations
slightly wrong, as if the text width were being calculated using information
about one font, but the text was actually printed using a different font. The
tipoff is URLs and other underlined text. The underlines indicate how wide the
layout engine thought the text would be.

JP, could you find a small page that demonstrates the problem, print it to a
file, and attach the postscript file to this bug?

Comment 4

[JP]

Attachment: Postscript generated by 'print to file' (using default postscript printer command)

I have added an attachment which is the postscript generated by the 'print to
file' command.	Subsequent attachments will show:
a) the actual printout (scanned) this postscript generates using lpr in a
shell, which is also exactly what is generated when printing directly to the
default postscript printer in Mozilla.
b) the actual printout generated when using the alternative command for the
default postscript printer in Mozilla. (mozprintfile=`tempfile`; cat >
$mozprintfile && gs -sDEVICE=ljet4
-sOutputFile=\|lpr -dNOPAUSE $mozprintfile && rm $mozprintfile).

Comment 5

[JP]

Attachment: a) actual printout (scanned) of postscript

Refer to previous comment.  This is the actual hardcopy of that results from
using lpr in a shell on postscript generated by Moz.  If I print directly to
the default postscript printer in Mozilla I also get _exactly_ this appearance.
 (The page I was printing is google.co.nz).

Comment 6

[JP]

Attachment: b) actual printout generated using an alternative command for the default postscript printer in Mozilla

Refer to previous comments.  This is the actual hardcopy using an alternative
printer command for the default postscript printer: 
mozprintfile=`tempfile`; cat >
$mozprintfile && gs -sDEVICE=ljet4
-sOutputFile=\|lpr -dNOPAUSE $mozprintfile && rm $mozprintfile

Comment 7

[Kenneth Herron]

The postscript attachment was generated from a copy of mozilla using the
freetype extension; the font being used is embedded in the document. When I view
the file with ghostview I get results like the second jpeg. It's as if metric
(character-width) data from one font was used to lay out the page, but then
either a different font was embedded into the document, or the metric data
included in the document is wrong, or the font scale is a bit small. The
difference in the two jpegs suggests that ghostscript and your printer are
interpreting the font metric information a bit differently.

CC'ing jshin.

Comment 8

[JP]

(In reply to comment #7)

Thanks for taking a look at this Kenneth.

Here's the thing -- if I run the thing through ghostscript first, then my
printer (via CUPS, using ljet4 which would be one of the more common printers in
use), it works fine.  See the alternative printer command above.

If, alternatively, I use the raw postscript generated by Mozilla (the default
print command and postscript printer) and pump it straight through CUPS, it
doesn't work.

That suggests to me that Moz is producing some postscript that is maybe too
advanced for my system, and that gs will translate it into something simpler. 
Sound likely?  Admittedly, this might mean I just need to upgrade, but this
would be breakage for a significant number of people using Debian stable.

Cheers
JP

Comment 9

[Jungshik Shin]

> That suggests to me that Moz is producing some postscript that is maybe too
> advanced for my system, and that gs will translate it into something simpler.

  When you filtered the Mozilla-generated PS file with ghostscript, you used
'ljet4' device. 'ljet4' device driver in ghostscript is not for postscript
printers but it translates postscript files to PCL5/6 (I forgot which variant of
PCL HP LJ4 supports). 

  Can you also try '-sDEVICE=pswrite -dLanguageLevel=2' instead of
'-sDEVICE=ljet4'? 'pswrite' device does what you thought 'let4' device did
(translating PS level 3 to PS level 2). Apparently, your printer supports PS
level 3 so that you wouldn't need the level downgrading if there were no problem
with spacing/metric. 

Anyway, I agree with Kenneth on his diagnosis in comment #7, especially the
following:

> ghostscript and your printer are interpreting the font metric information
> a bit differently

  Could you tell me the model number of your printer and print the following PS
file?  
----------
%!PS
/Times-Roman findfont 12 scalefont setfont
50 700 moveto currentpoint
(The Postscript interpreter in your printer is ) show
version show
showpage
%%EOF
---------

Comment 10

[JP]

(In reply to comment #9)

Thanks for your further investigation.

My printer is a Brother HL-660, running in laserJet4 emulation mode.  To my
knowledge, it does not support postscript at all (there is an add-on board
available, but it is not installed).  Hence, I normally just use CUPS with the 
ljet4 driver, and that normally works.  As far as I know, CUPS handles the
postscript to PCL translation (but I don't know much about CUPS).

When I tried substituting your command for mine, nothing happened, which was a
surprise.  I checked the spelling several times, including case, but the
printer's Data light never even blinks.  For the record, I have copied and
pasted it below, just in case I got something wrong:
mozprintfile=`tempfile`; cat > $mozprintfile && gs -sDEVICE=pswrite
-sOutputFile=\|lpr -dLanguageLevel=2 -dNOPAUSE $mozprintfile && rm $mozprintfile

If instead I print to a file, then use the following commands in the shell, I
get a perfect printout (though I have to manually quit out of gs before it happens):
gs -sDEVICE=pswrite -sOutputFile=mozilla2.ps -dLanguageLevel=2 -dNOPAUSE
mozilla.ps && lpr mozilla2.ps

I printed the few lines of postscript code at the bottom of your comment using
the CUPS lpr command, and got:
The Postscript interpreter in your printer is 3010.

Given the use of CUPS and the lack of native postscript support in the Brother,
I'm assuming that number was generated by CUPS?

Maybe my CUPS ps->PCL translator can't handle PS level 3?  

Cheers
JP

Comment 11

[Jungshik Shin]

JP>My printer is a Brother HL-660, running in laserJet4 emulation mode

Kenneth> ghostscript and your printer are interpreting the font metric information
Kenneth> a bit differently

So, the above should be changed to :

ghostscript and whatever CUPS uses to translate mozilla-generated PS files to
PCL5/6 (that HP LJ4 or your printer brother HL understands) are interpreting the
font metric information a bit differently. 

Comment 12

[JP]

(In reply to comment #11)

I have switched from the native CUPS v1.1 ljet4 driver to the foomatic ljet4
driver using the latest foomatic-rip, foomatic-gswrapper and
Brother-HL-660-ljet4.ppd from linuxprinting.org.

If anyone out there wants to know how to do this with Debian Woody:
Dowload the files.  Pop the foomatic files in /usr/bin and chmod 755.  Soft link
/usr/lib/cups/filter/foomatic-rip to /usr/bin/foomatic-rip.  Pop the ppd in
/usr/share/cups/model/.  Restart cupsys.  Set up a new printer using the driver.

I now have no problems with fonts being widely spaced, so I take that bug to be
a problem with the native CUPS driver.

I still get some misalignment of underlined (linked) text on this page:
http://members.rogers.com/dpjames/firebird/pinball.html

In particular, _Pinball Theme_ buts up hard against words on both sides.  This
happens for hard copy or using gs to view generated postscript on screen.  I
will attach postscript (see next comment).

Underlined links on this page worked fine:
http://www.linuxprinting.org/cups-doc.html

Cheers
JP

Comment 13

[JP]

Attachment: Linked text not printing correctly (http://members.rogers.com/dpjames/firebird/pinball.html)

Postscript printout of http://members.rogers.com/dpjames/firebird/pinball.html.


Printing or viewing on screen with gnu ghostscript 6.53, the linked text prints
misaligned.

Printer: Brother HL 660 with CUPS using latest foomatic driver and ljet4 ppd
from linuxprinting.org.

Comment 14

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 15

[Peter Weilbacher]

The remaining issues seem to be covered by bug 109970.

*** This bug has been marked as a duplicate of 109970 ***