Print 'MS Sans Serif' will result in garbage




Printing: Output
9 years ago
9 years ago


(Reporter: henriko, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)




(3 attachments)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv: Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv: Gecko/2008120122 Firefox/3.0.5

Firefox 3 can not print certain webpages. The result is complete garbage. But on screen it looks correct.

The problem do not exist in old Firefox 2. The same pages get correctly printed in Firefox 2.

My investigation led me to the use of the font 'MS Sans Serif'. (At least I could not find any other font that gave this kind of garbage.)

I have tested on four different printers. (Five including PDF-Cretor)

Based on the driver name including terms like PS and PCL, I guess two of them is using postsscript, and two PCL of differnt generations. They are made by different manufactures. So in my point of view, this looks like an Firefox 3 specific bug. And has nothing to do with drivers and such, like in

One working workaround is the "Tools->Options->Content->Fonts&Colors->Advanced->Allow pages
to choose their own fonts". But most webbpages get very ugly. Looks like yet another bug, to me. Looks like Firefox does not even use font families and the manually choosen fonts in "Tools->Options->Content->Fonts&Colors->Advanced" when this workaround is used. It seems that it is only using the defual font in "Tools->Options->Content->Fonts&Colors".

Another workaround that works is to preview the webpage first, and then use print inside the preview window. Unfortunately this will results in yet another bug, I think. If the page you are trying to print is frame based, then the print preview tells you that one page will be written. But then it will come out a bunch of papers, on for each frame. So this will workaround will consume a lot of paper. If the print preview said that it will be several pages generated, then you could choose only one of them.

An extra observation is that the use of 'Small Fonts' will look as expected on screen. But when printed that font is not used. At least this does not look like garbage, and it can be read.

Reproducible: Always

Steps to Reproduce:
Use Firefox 3 (I use 3.0.5)

1. Load my sample webpage

2. Print it (without using print preview)

Actual Results:  
The second paragraphs is not printed correctly, like on screen. Its not readable at all. Only garbage.

This is how it looks when I print it out:

Expected Results:  
I expected that both paragraphs should be readable, like it is on the screen.

Yes, I have searched the bugzilla for similar bugs. And yes, there are a lot of printing garbage bugs. But I did not found anyone that specificly points to the use of the font MS Sans Serif in Firefox 3.
Component: General → Printing: Output
Product: Firefox → Core
QA Contact: general → printing
Version: unspecified → 1.9.0 Branch


9 years ago
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 454532
Created attachment 357994 [details]
testcase from URL

I'm attaching the testcase given at the URL, in case it gets tweaked or removed from that host.
Created attachment 357998 [details]
PDF Printout of testcase (using Bullzip

I can reproduce this bug using 2 additional free PDF printers, with Firefox 3.0.5 on Windows Vista:
  - CIB pdf brewer, version 2.5.22 (latest)
  - Bullzip PDF printer, versions 4.0.462 (old) and (latest)

I'm attaching the PDF from Bullzip PDF Printer v6.0.0.741 here.  It looks pretty much the same as the PDF linked in comment 0.
Created attachment 358001 [details]
PNG Printout of testcase (using Bullzip

Here's the testcase printed to PNG (& hence viewable directly in Firefox), since Bullzip supports that now. :)
I can also reproduce in m-c latest-nightly:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090121 Minefield/3.2a1pre
  Version --> Trunk
Version: 1.9.0 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.