Bug 1112 - something really screwy going on with default firefox fonts
Summary: something really screwy going on with default firefox fonts
Alias: None
Product: xprint
Classification: Unclassified
Component: Server: Font engine: Other (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: high normal
Assignee: Roland Mainz
QA Contact:
URL: http://www.debian.org
Depends on:
Reported: 2004-08-17 18:57 UTC by Drew Parsons
Modified: 2011-09-13 14:01 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Description Drew Parsons 2004-08-17 18:57:54 UTC
As discussed already in Debian bugs #235592, #251067 (and elsewhere - I'm
starting to lose track...), a default unstable Debian installation of firefox
(0.9.3-2) and Xprint (0.0.9.final.001-3), i.e. 009.001) is no longer capable of
print Debian's own home page correctly (!). The same applies for the mozilla
browser too, I believe.

The problem is that the main text on www.debian.org gets rendered as sans-serif,
with all spaces between words removed.

It would be nice to say to the problem lies in firefox (I think firefox 0.8 was
still working, but that was with Xprint 009), but it's not as simple as that. 
If I downgrade Xprint from 009.001 to 009, then firefox 0.9.3 starts to print
the page properly (serif+spaces) again.  Which really does suggest the problem
is ours, Xprint's.

On the other hand, the reported of bug #251067 has suggested a workaround:
create userContent.css (copy from userContent-example.css) inside the .mozilla
(.firefox) default chrome directory (~/.firefox/default/<user-specific>/chrome).
In it, place:

@media print {
         body {
             color: black;
             font-family: 'Times New Roman', times, serif;
             font-size: 12pt;
         tt, pre {
             font-family: 'Courier New', courier, typewriter, monospace;
         :link, :visited {
             color: black !important;
             text-decoration: underline !important;

Actually, this simpler version works better I think:

@media print {
         body {
             font-family: times, serif;
         tt, pre {
             font-family: courier, monospace;

This causes the main text to be rendered as serif, with proper spacing.

Since this fix is in firefox, it's difficult to say Xprint or firefox alone is
responsible. Maybe the Xprint printing code inside mozilla needs reviewing?

Since Debian is very close to releasing the next stable version, it'd be a
little embarrassing if we could not print our own home page properly without
special tweaking by the user...  Time is short....


p.s. while looking at font handling, it seems appropriate to mention Xprint bug
#6306, http://bugzilla.mozdev.org/show_bug.cgi?id=6306, which can also be seen
on www.debian.org (arial/helvetica fonts honoured by Xprint, but not by mozilla
on screen).
Comment 1 Drew Parsons 2004-08-18 01:26:47 UTC
Fortunately it turns out this problem is only restricted to firefox.  mozilla
1.7.2 prints the Debian webpage just fine (using Xprint 009.001).

Comment 2 Drew Parsons 2004-08-21 22:05:14 UTC
Another Debian user suggests a different workaround: remove the Xprint fonts
directory, /usr/share/Xprint/xserver/C/print/models/PSdefault/fonts.

When this is done, the text gets printed with proper spacing.

But it is all rendered as sans-serif (even <tt> elements, which should be
monospace not sans-serif).

This suggests there is some mismatch in getting font information, no?

Also, the original reporter confirms that he experiences the problem on mozilla
1.7.2, even though I can only see it under firefox.
Comment 3 Jay Smith 2004-09-05 16:53:27 UTC
We have just installed Mozilla 1.7.2 running on RedHat 8 linux.

Due to other unrelated problems we had using kprinter with Mozilla 1.6 in our
environment (resources issues running mozilla on linux through Xwindows supplied
by Cygwin on Windows95); seemingly Win95 resources issues causing Cygwin to
crash), we are trying to use XPRINT for our Mozilla 1.7.2

We encountered two problems:

1) *Mail* page headers and footers were missing spaces and numerals. Utilizing
info in http://www.jw-stumpel.nl/stestu.html (Section 9 - Printing, Mozilla,
Xprint) we "moved aside" the fonts directory.  This solved the missing spaces
and numerals issue.  However, as the referenced webpage indicates it does *not*
solve the other problem...

2) The message body (and message header) is being printed in a san-serif,
proportionally spaced font instead of the serif (courier) fixed-width font that
is a) specified in the Mozilla preferences, displayed on the mail screen, and
displayed in the print preview.

This (#2) is an important problem because a lot of the mail we print contains
columns of numbers that have been created using fixed-width font. They are
virtually unusable when printed in a proportional font.

In our installation, we have been unable to find the location of the CSS file
(containing the @medial print) referenced by the original poster. However, I
strongly suspect that there must be another CSS file somewhere that handles the
MAIL css.  Any ideas on that??????


Comment 4 Drew Parsons 2004-09-08 23:57:40 UTC
The CSS file on Debian systems seems to come from
I think when a new user profile is created (creating ~/.firefox or ~/,mozilla),
the default files are copied from here into the user's new firefox config directory.

I don't know how RedHat has mozilla set up, but I imagine it couldn't be that
much different.  It would make sense that they have the same default profile,
perhaps in their case the directory is simply empty?

I'm not sure about mozilla mail, however, sorry.

Comment 5 Jay Smith 2004-09-09 10:56:46 UTC
Unfortunately, I am still not finding the relevant .css file for Mozilla 1.7.2
on RedHat Linux 8 so that the xprint fix can be implemented.

There are no css files in /home/username/.mozilla/username/blah/

There are css files in /usr/lib/mozilla-1.7.2 (in res/) but none that seem to
match the name or description given in the fix.

So.... ?

Meanwhile, though services says that xprint is still running, it has
spontaneously become not available to Mozilla (this happened while Mozillas were
running, NOT after any reboots, restarts, relogins, or mozilla starts).  So now
I have to figure out why xprint died as far as Mozilla is concerned. (It is
still dead to Mozilla after logging out and logging back in and restarting Mozilla.)

Comment 6 Drew Parsons 2004-09-22 02:04:10 UTC
Jan Willem Stumpel suggests the follow addition to the userContents.css file, in
the @print section:

       .moz-text-plain {
        font-family: 'Courier New',courier,monospace !important;

This is reported to fix the thunderbird/mozilla-mail printing problem described
by Jay.  The !important directive is required.  Further information might be
extracted from files at
Comment 7 Jay Smith 2004-09-22 11:18:13 UTC
I had been corresponding with Jan and I tested Jan's CSS fix a few days ago. At
first I thought it had fixed the problem.  I added the CSS, started mozilla,
etc., printed, and the fonts worked correctly.

HOWEVER, the next morning the font fix no longer worked.  The CSS content was
still there, but the fonts were back to their old proportional sans-serif self
when printing using Xprint.

This is on Mozilla 1.7.2 running on Red Hat 8, with the latest Xprint.

HOWEVER, in the last couple days I have done a lot of experimenting with
Mozillas preferences using the GUI (Edit, Preferences, Appearance, Fonts...) AND
using Mozilla about:config.  I got extremely bizzare results....

a) Using about:config I *can* PRINT the mail message body with fixed width high
quality courier font.  To do this I set:

   font.name.monospace.x-western   =   adobe-courier-iso8859-1

b) However, doing that causes the on-screen display for reading and composing
messages to be a san-serif monospaced font -- not courier (at it had been
previously).  It is a good quality font for what it is, but it would not be my
first choice. However, I can live with it.

c) There seems to be no way to set adobe-courier-iso8859-1 via the GUI. (At
least Mozilla does not know where to find that font name.)  When doing it via
about:config, it shows up in the GUI as "monospace".  However, if you were to
select monospace font (for the monospace list) in the GUI, you would get
"monospace" in the about:config -- and you will NOT get the same result as using

d) ALL attempts to set the monospaced font via the GUI have resulted in being
unable to PRINT monospaced/courier.  Those attempts show a variety of DISPLAY
fonts, most not acceptable/readable.

e) Various experiements in about:config to turn on/off:
resulted in NO change in printing (or on screen).

f) Experiments to define fonts for xprint similar to Mozillas definitions for
to be something like
resulted in NO change.

g) Jan additionally pointed out that when he tested using the GUI, he found that
even just *looking* at the settings in the GUI (and then canceling the dialog)
resulted in inappropriate and incorrect changes to the preferences as shown in
about:config.  Wow!  What a mess.

There is still no clue why the "To:" is missing from the mail message header
when printing the mail message.  I have this problem and my systems guy has this
problem on a similar installation (RH*, etc.), both with Mozilla 1.7.2 AND now
with 1.7.3.

Comment 8 Antonio C. Censi 2004-12-14 14:35:02 UTC
(In reply to comment #7)
> I had been corresponding with Jan and I tested Jan's CSS fix a few days ago. ....

Complimentary information:

Packages versions: mozilla-firefox and xprt-xprintorg - current unstable versions 

a) Printing is wrong even with userContent.css fix suggested in package
documentation and bugzilla in Debian and freedesktop.

b) In printing a page from Livermore Labs (
http://www.llnl.gov/str/November04/Louis.html ), I noticed that everytime a
quote (") or apostophe (') appears in text, the WHOLE printed line containing
the quote is printed without spaces, even before the quote.

I hope that could be of some help.
A. C. Censi
accensi [em] gmail [ponto] com
accensi [em] montreal [ponto] com [ponto] br
Comment 9 Drew Parsons 2004-12-14 15:29:27 UTC
Another data point: the mere fact of setting firefox fonts messes up the
printing of www.debian.org. I've placed this information in Debian

   "The printing error will start happening if you change font settings
   using Edit->Preferences (in particular if you set the serif font).
   Changing the setting back again to the default value of "serif" will
   not fix the problem.

   This is because setting the font places a "font.name.serif.x-western"
   entry into ~/.mozilla/firefox/default.***/prefs.js.  Even if the value
   of the entry is "serif", it's mere presence will ruin printing.

   The workaround is to manually delete the "font.name.serif.x-western"
   entry from prefs.js.

   This seems to fix the problem with the Debian home page, but depending
   the page and language you want to print with you might find you will need
   to delete other font.name entries as well."

When firefox fonts are removed from pref.js in this way, then www.debian.org
prints fine without the spaces problem.

Unfortunately, Antonio's new test case at
http://www.llnl.gov/str/November04/Louis.html nevertheless still misprints on
lines with ".
Comment 10 Drew Parsons 2005-01-18 18:40:58 UTC
Here is another bizarre data point for the font-handling bugs.
The bottom of the Debian home page (http://www.debian.org/) has links to other
languages.  For some reason, on my screen the Asian symbols (CJK) are not
rendered at all, they are replaced with a box containing the Unicode number inside.

When I print using Xprint, however, then the symbols are printed correctly. 
Xprint is able to find and handle the fonts, while XFree86 cannot.  Very odd,
but nice to know that Xprint is ahead this time.

Unfortunately the reverse is true for mathML. Using the test pages at
http://www.w3.org/Math/testsuite/ (e.g. TortureTests->Complexity->Complex1),
most of the maths is rendered on screen (firefox does give me a warning that I
am missing some fonts, and so some symbols are missing), but essentially none of
it is printed by Xprint.
Comment 11 Corbin Simpson 2011-09-13 14:01:03 UTC
Closing WONTFIX because nobody cares about Xprint. Reopen if you plan to address this bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.