There have been many reports of incorrect font glyphs printing when certain, old Windows printer drivers are used, similar to bug 432071. Such printers/drivers that have been reported on support.mozilla.com include: *Richo Aficio 220 PCL 5e, works with updated driver *Sharp AR-M208 with GDI driver, "improved" with updated driver. After updating the driver, when printing http://www.w3.org/Style/Examples/007/fonts , only the "cursive" fonts printed. *Lexmark z82 *Compaq 1400P *Lanier 5227 (See attachment) *Acrobat PDFWriter 4.0 (see attachment)

We need to at the very least figure out what pieces these old print drivers don't like; I'll take this.

I had a look at all these bug reports for printing garbled text to see if i can work out what is going on. I have found the following bug reports for garbled text when printing. There may be others I have missed. bug 439841 - unspecified printer and MS imaging printer bug 444012 - Adobe PDF Writer 4 bug 449601 - Ricoh Models Aficio 1018d and 2205 bug 452289 - unspecified version of PDF Writer bug 452374 - Adobe PDF Writer 3 bug 446513 - unspecified PDF printer bug 454521 - Adobe PDF Writer 5 bug 440529 - unspecified version of PDF Writer and Win2PDF pro 3.20 bug 426438 - HP Laserjet 2200dn with PCL6 drivers, HP Laserjet 8100n, SHARP AR M35, Minolta Di520, HP LaserJet 5000, Imagistics im3510 bug 454789 - unspecified printer bug 422253 - Adobe PDF Writer 3, 4, 5, 7, 8 and the following web pages: http://bugzilla.zimbra.com/show_bug.cgi?id=29379 http://www.solo-technology.com/blog/2008/05/20/firefox-3-rc1-printing-garbage/ After reading through all these bug reports there appears to be at least two separate bugs: 1) Firefox always prints garbage with Adobe PDF Writer. No known workaround. 2) Firefox prints garbage text on some printers for some people. Some people experiencing this bug have found workarounds to make it work. Adobe PDF Writer ---------------- I located a machine with Acrobat 5 and did some testing. Acrobat 5 comes with two printer drivers: PDF Writer and Distiller. Printing from Firefox 3 to Distiller works fine. Printing to PDF Writer produces garbage. I also tested printing to PDF Writer with cairo using some simple test code and got the same garbled text. Further testing revealed that: - Both cairo_win32_printing_surface and cairo_win32_surface have the same problem. - Changing the various PDF Writer font embedding options did not make any difference. - Trying various fonts did not make any difference. It appears that PDF Writer 5 ignores the ETO_GLYPH_INDEX option. Passing in glyph indices that are actually unicode characters produces correct output. I also testing printing from Internet Explorer to PDF Writer 5. It produced correct output for latin characters but incorrect output for other alphabets. Looking at the PostScript output from IE it can be seen why. IE is not using ETO_GLYPH_INDEXING for latin text but is for other characters. In the PS output, using ETO_GLYPH_INDEX results in strings of ascii hex <0102030405> while not using ETO_GLYPH_INDEX results in text strings (abcde). According to the Wikipedia page on Acrobat, PDF Writer was dropped starting from version 6. This would explain why most of the bug reports for printing with Acrobat are for versions 5 and earlier. I suspect that bug reports for later versions are actually the other bug discussed below. I did find a report of some versions of Visio having the same problem with PDF Writer: http://support.microsoft.com/kb/318324/en-us?spid=2529&sid=49 Possible solutions to this bug are: 1) Convert glyph indices to Unicode where possible like IE does. This would be a lot of work to support a broken and obsolete printer driver. It would also only work for latin text. Interestingly Microsoft has introduced a new ExtTextOut option in Vista for reversing the glyph indices back to Unicode where possible to improve printing speed with CJK fonts: http://blogs.msdn.com/michkap/archive/2007/09/24/5082103.aspx 2) Use Distiller instead of PDF Writer. And in more recent version of Acrobat this is the only option. 3) Fix the remaining issues with the cairo PDF export and make this available from the user interface. This is my preferred solution :-). Other Printers -------------- There have been a lot of bug reports for printing garbled text on various printers. Not every one with the same printer experiences the bug. I have tried installing printer drivers for some of the printers mentioned and have been unsuccessful in reproducing the bug. Various workaround have been found that make Firefox print correctly including: - changing the default font from "Times New Roman" to "Trebuchet" - upgrading to the latest print drivers but does not for work for everyone - going to print preview first then printing - changing the default character encoding The first one suggests that Times font built in to the printer is being substituted. Although according to the above web page, printing with ETO_GLYPH_INDEX overrides font substitution. According to this page: http://bugzilla.zimbra.com/show_bug.cgi?id=29379 the problem is caused by mapping of courier to the Windows bitmap courier font. This is substituted with a device font when printed. In the laser printer scan in comment #1 it can be seen only some of the text is garbled and it appears to be a Helvetica font that has been substituted. So it looks like this bug is related to bug 432071, bug 396315, and bug 432065. Is Firefox using the printer DC when mapping characters to glyphs? This may make a difference when fonts are substituted when printing. Did this patch make it into Firefox 3? Without it the DC returned by the win32 printing surface is always NULL: http://gitweb.freedesktop.org/?p=cairo;a=commit;h=141bca74ba154d79fab49db74a51cd41f04e3a34

Adrian, thanks for the great analysis! (In reply to comment #3) > [PDF Writer] > Possible solutions to this bug are: > > 1) Convert glyph indices to Unicode where possible like IE does. This would be > a lot of work to support a broken and obsolete printer driver. It would also > only work for latin text. Interestingly Microsoft has introduced a new > ExtTextOut option in Vista for reversing the glyph indices back to Unicode > where possible to improve printing speed with CJK fonts: > > http://blogs.msdn.com/michkap/archive/2007/09/24/5082103.aspx > > 2) Use Distiller instead of PDF Writer. And in more recent version of Acrobat > this is the only option. > > 3) Fix the remaining issues with the cairo PDF export and make this > available from the user interface. This is my preferred solution :-). I agree with going with option 3 -- we should also detect PDF Writer and notify the user that this isn't going to work and that they should use Distiller or something. Doing this notification sounds painful, though, but it's doable. Also, we won't be able to fix that for firefox 3.0, would have to go into 3.1. > Other Printers > -------------- > Is Firefox using the printer DC when mapping characters to glyphs? This may > make a difference when fonts are substituted when printing. Did this patch make > it into Firefox 3? Without it the DC returned by the win32 printing surface is > always NULL: > > http://gitweb.freedesktop.org/?p=cairo;a=commit;h=141bca74ba154d79fab49db74a51cd41f04e3a34 The patch didn't make it in -- is that in 1.6.x? I'm tempted to do a cairo upgrade on the 3.0 branch to at least the latest 1.6 cairo release, which should be safe.

(In reply to comment #4) > The patch didn't make it in -- is that in 1.6.x? I don't think it is. Bug 452247 also looks to be a result of the switch to ETO_GLYPH_INDEX.

(In reply to comment #4) > I agree with going with option 3 -- we should also detect PDF Writer and notify > the user that this isn't going to work and that they should use Distiller or > something. Doing this notification sounds painful, though, but it's doable. > Also, we won't be able to fix that for firefox 3.0, would have to go into 3.1. Is PDF Writer that common? I'm just wondering why this deserves in-UI notification instead of a release note or other somesuch like we do with other incompatibilities. Were we to do something in the UI, at the point of printing when we detect that printer as being selected would be best.

(In reply to comment #3) > I also testing printing from Internet Explorer to PDF Writer 5. It produced > correct output for latin characters but incorrect output for other alphabets. > Looking at the PostScript output from IE it can be seen why. Adrian: If you still have your setup (or testcases) handy, would you mind attaching a sample HTML testcase that prints incorrectly in IE using PDF Writer? Such a testcase would be useful on the many dependent / duped bugs of the form "Firefox prints gibberish using Obscure Printer X". While we may not be able to test "Obscure Printer X" locally, we could have the reporter try printing this hypothetical testcase in IE to determine if the root cause is the same sort of ETO_GLYPH_INDEX printer-driver-bug that you described in comment 3.

(In reply to comment #11) > > Adrian: If you still have your setup (or testcases) handy, would you mind > attaching a sample HTML testcase that prints incorrectly in IE using PDF > Writer? I don't still have copies of the test results but it is simply a case of printing pages with non latin text. I used sites such as: http://www.debian.org/ http://www.gnu.org/software/software.html that have links to translations at the bottom of the page. > Such a testcase would be useful on the many dependent / duped bugs of the form > "Firefox prints gibberish using Obscure Printer X". While we may not be able > to test "Obscure Printer X" locally, For PCL and PostScript printers (ie most of the printers out there) it is possible to test "Obscure Printer X" locally by installing the driver and printing to a file. Then view the file with Ghostscript or a PCL viewer. I have done this for many different printers while investigating this bug. > we could have the reporter try printing > this hypothetical testcase in IE to determine if the root cause is the same > sort of ETO_GLYPH_INDEX printer-driver-bug that you described in comment 3. As I mentioned in comment 3 I believe the problem with garbled text on random printer X is a different bug to the PDF Writer bug. It appears to be related to previous bugs where Firefox selects a bitmap font when a font such as Times or Courier is requested but when printed Windows substitutes a printer font.

I suppose someone could go make all those dupes blockees instead. I just felt duping was easier since people don't usually notice that they have to track dependencies.

Using Firefox 3.0.3 I have been printing "test case" in bug 396315 (https://bugzilla.mozilla.org/attachment.cgi?id=281051) to both my HP LaserJet using a PCL driver and to CutePDF. I have been able to intermittently get garbled text for either "Courier" or "Small Fonts". I've seen "Small Fonts" print a garbled bitmap font, a garbled Arial font and a correct Arial font at different times. I did manage to get "Courier" to print garbage (in a non bitmap Courier font) to the printer. I have not found any consistent way to reproduce this. I get different results when: - Using a new profile - Going to print preview first - Browsing various pages for a while then printing - Printing immediately after starting Firefox. Vlad: when it the upgrade to cairo 1.8 planned? It would be interesting to see what effect using the printer DC or any of the other bug fixes has.

Hi there! I can test lot of new and high quality printers. Can I help? I have actually the printing problems on really new HP Laser Printers and Copiers from Toshiba/Konica with new drivers (PS or PCL - it doesn't matter).

Adding HP LaserJet 2100

(In reply to comment #22) > Adding HP LaserJet 2100 Can also add: Brother a HL-1240, Sharp ARP-350 and PDFWriter 5.0.5 (german version). Seems to affect a broad range of products.

Well, i like to add HP Laserjet 5, HP Laserjet 3015, Konica 7035 (Copystation with Scanner and Printer), Toshiba Studio 120 and PDFCreator 0.9. The problem appears even with the new universal printer driver by HP.

(In reply to comment #3) > 2) Use Distiller instead of PDF Writer. And in more recent version of Acrobat > this is the only option. I'm using Acrobat Reader 5 on WinXP2 and Firefox 3.0.3 When Using Distiller and print the page for the first time, the problem still appear for site that using CSS media="print". After clicking "print preview" the problem gone... @zaenal

Sorry

Comment on attachment 347493 [details] (useless attachment; ignore) theguyyouseeeveryday, please don't make useless attachments/comments. --> obsoleting attachment 347493 [details]

Can add: SHARP AR-M350 PCL6, driver version 3.5.0.3 from 03/12/2002 and 3.6.2.37 from 07/15/2004, no newer drivers found for Windows XP only workaround is print preview before printing, font "Trebuchet MS" instead of Times New Roman did not help, no change too with ISO8859-15 od Windows-1252 instead of ISO8859-1 as default character encoding Website was: http://h18006.www1.hp.com/products/storageworks/san/index.html

The problem also occurs on the Brother HL-1060. I do not have this problem when printing to the Win2PDF from DanePrairie though.

(In reply to comment #12) > (In reply to comment #11) > > As I mentioned in comment 3 I believe the problem with garbled text on random > printer X is a different bug to the PDF Writer bug. It appears to be related to > previous bugs where Firefox selects a bitmap font when a font such as Times or > Courier is requested but when printed Windows substitutes a printer font. If this can be of any help, the problem still occurs even when I have configured for my printer to print all Truetype fonts as graphics...

I just experienced this with Firefox 3.0.4, running on Windows 2000 SP4. I'll check other platforms (XP, CentOS) later. Printer is an HP4050TN, connected via JetDirect. The problem occurs with the PS driver version 4.00, and affects the header and footer as well as some parts of the web page being printed. In some cases, only the header and footer are garbled. I seem to have a workaround by using PCL5e instead of PS. I did not have this problem with Firefox 2.

I'm experiencing the PDFWriter (5.0) problem on FF3.0.5 The funny thing is that it was working fine. I used copy commander to flash up a new hard drive, to only find out that i lost all my preferences and user account settings. After manually resolving those issues the only problem left is firefox won't print correctly with pdfwriter 5.0. distiller works fine. Problem is pdfwriter makes much smaller pdf's than distiller.

Can anyone who can reproduce this bug check if the latest nightly build fixes it? My best guess is that this caused by getting glyph indices for a device font on a non printer context. The latest nightly build should have the cairo fix for returning the correct printer context. A very good article on the use of device fonts is at: http://support.microsoft.com/kb/201978 One of the things it mentions is that font metrics must not be mixed between the printer DC and other contexts. I would expect this applies to character to glyph mapping as well. There is another bug (bug 463148) for incorrect character spacing when printing on Windows that could be caused by the same issue. Does firefox lookup the glyph indices on the printer context when printing or cache them from the display context? The above article also noted that fonts enumerated from the printer context do not necessarily work on a display context. I don't know if the reverse is true although I have seen a printer context return a different font than the display context for the same font name (substituting a device font for a bitmap font). A number of bug reporters noted that doing print preview before printing fixed the problem. I'd be interested to know what print preview is doing that could affect the character to glyph index mapping used when printing.

(In reply to comment #34) > Problem is pdfwriter makes much smaller pdf's than distiller. The reason that pdfwriter creates smaller PDFs is because it does not embed that standard PostScript fonts (Time, Helvetica, Courier etc). However this can cause problems if the viewer does not have these fonts available or the font metrics of the viewer fonts are not exactly the same as what PDFWriter was using. Since PDF version 1.5 Adobe has deprecated the "no need to embed the font if it is one of the standard fonts" feature.

I've found a method to consistently reproduce this using this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081221 Minefield/3.2a1pre 1. Open the attachment https://bugzilla.mozilla.org/attachment.cgi?id=281051 ("test case" in bug 396315). I opened it from a file in case that makes a difference. 2. Print it to a file. I used the print driver "HP Laserjet 4050 Series PS" that comes with XP. The PostScript output is blank when viewed in GSview. I don't know if this is a separate bug or a side affect of this bug. 3. Open this attachment. It is a cut down version of the attachment in step 2. Print it to a file. The PostScript output shows garbled text. This is very timing dependent. If I wait too long before opening the second file or after opening the second file I wait too long before printing the output is fine. Repeating the procedure sometimes reproduces the bug and sometimes it doesn't. Closing the browser and starting again always reproduces the bug. I've tried both the PS and PCL drivers for the LaserJet 4050 included with XP as well as the latest HP universal print driver for PCL or PS and in all cases can reproduce the problem by printing to my printer or printing to a file and viewing with a PostScript or PCL viewer.

I can also reproduce the bug using the PDF Creator print driver by following the procedure in comment #37.

(In reply to comment #3) > I had a look at all these bug reports for printing garbled text to see if i can > work out what is going on. I have found the following bug reports for garbled > text when printing. There may be others I have missed. > > bug 439841 - unspecified printer and MS imaging printer > bug 444012 - Adobe PDF Writer 4 > bug 449601 - Ricoh Models Aficio 1018d and 2205 > bug 452289 - unspecified version of PDF Writer > bug 452374 - Adobe PDF Writer 3 > bug 446513 - unspecified PDF printer > bug 454521 - Adobe PDF Writer 5 > bug 440529 - unspecified version of PDF Writer and Win2PDF pro 3.20 > bug 426438 - HP Laserjet 2200dn with PCL6 drivers, HP Laserjet 8100n, > SHARP AR M35, Minolta Di520, HP LaserJet 5000, Imagistics im3510 > bug 454789 - unspecified printer > bug 422253 - Adobe PDF Writer 3, 4, 5, 7, 8 > > and the following web pages: > > http://bugzilla.zimbra.com/show_bug.cgi?id=29379 > > http://www.solo-technology.com/blog/2008/05/20/firefox-3-rc1-printing-garbage/ > > > After reading through all these bug reports there appears to be at least two > separate bugs: > > 1) Firefox always prints garbage with Adobe PDF Writer. No known workaround. > > 2) Firefox prints garbage text on some printers for some people. Some people > experiencing this bug have found workarounds to make it work. > > > Adobe PDF Writer > ---------------- > I located a machine with Acrobat 5 and did some testing. Acrobat 5 comes with > two printer drivers: PDF Writer and Distiller. Printing from Firefox 3 to > Distiller works fine. Printing to PDF Writer produces garbage. I also tested > printing to PDF Writer with cairo using some simple test code and got the same > garbled text. Further testing revealed that: > > - Both cairo_win32_printing_surface and cairo_win32_surface have the same > problem. > > - Changing the various PDF Writer font embedding options did not make any > difference. > > - Trying various fonts did not make any difference. > > It appears that PDF Writer 5 ignores the ETO_GLYPH_INDEX option. Passing in > glyph indices that are actually unicode characters produces correct output. > > I also testing printing from Internet Explorer to PDF Writer 5. It produced > correct output for latin characters but incorrect output for other alphabets. > Looking at the PostScript output from IE it can be seen why. IE is not using > ETO_GLYPH_INDEXING for latin text but is for other characters. In the PS > output, using ETO_GLYPH_INDEX results in strings of ascii hex <0102030405> > while not using ETO_GLYPH_INDEX results in text strings (abcde). > > According to the Wikipedia page on Acrobat, PDF Writer was dropped starting > from version 6. This would explain why most of the bug reports for printing > with Acrobat are for versions 5 and earlier. I suspect that bug reports for > later versions are actually the other bug discussed below. > > I did find a report of some versions of Visio having the same problem > with PDF Writer: > http://support.microsoft.com/kb/318324/en-us?spid=2529&sid=49 > > Possible solutions to this bug are: > > 1) Convert glyph indices to Unicode where possible like IE does. This would be > a lot of work to support a broken and obsolete printer driver. It would also > only work for latin text. Interestingly Microsoft has introduced a new > ExtTextOut option in Vista for reversing the glyph indices back to Unicode > where possible to improve printing speed with CJK fonts: > > http://blogs.msdn.com/michkap/archive/2007/09/24/5082103.aspx > > 2) Use Distiller instead of PDF Writer. And in more recent version of Acrobat > this is the only option. > > 3) Fix the remaining issues with the cairo PDF export and make this > available from the user interface. This is my preferred solution :-). > > > Other Printers > -------------- > There have been a lot of bug reports for printing garbled text on various > printers. Not every one with the same printer experiences the bug. I have tried > installing printer drivers for some of the printers mentioned and have been > unsuccessful in reproducing the bug. > > Various workaround have been found that make Firefox print correctly > including: > > - changing the default font from "Times New Roman" to "Trebuchet" > - upgrading to the latest print drivers but does not for work for everyone > - going to print preview first then printing > - changing the default character encoding > > The first one suggests that Times font built in to the printer is being > substituted. Although according to the above web page, printing with > ETO_GLYPH_INDEX overrides font substitution. > > According to this page: > http://bugzilla.zimbra.com/show_bug.cgi?id=29379 > > the problem is caused by mapping of courier to the Windows bitmap courier font. > This is substituted with a device font when printed. In the laser printer scan > in comment #1 it can be seen only some of the text is garbled and it appears to > be a Helvetica font that has been substituted. > > So it looks like this bug is related to bug 432071, bug 396315, and bug > 432065. > > Is Firefox using the printer DC when mapping characters to glyphs? This may > make a difference when fonts are substituted when printing. Did this patch make > it into Firefox 3? Without it the DC returned by the win32 printing surface is > always NULL: > > http://gitweb.freedesktop.org/?p=cairo;a=commit;h=141bca74ba154d79fab49db74a51cd41f04e3a34 Yes , having just been referred to your piece after unwittingly reporting the pdf-writer bug again (See Bug 472473) I agree that you've done a great job with this analysis. Has there been any progress since in terms of what can the "ignorant user" do fic the problem? -Philip S Lingard

(In reply to comment #40) Philip -- please don't quote an entire giant comment when replying to something, so as not to make this bug page longer than it already is. I'd recommend leaving the "In reply to comment #__" header, as I've done in this comment, and then only quoting any chunks that you specifically want to highlight / respond to.

(In reply to comment #40) > Yes , having just been referred to your piece after unwittingly reporting the > pdf-writer bug again (See Bug 472473) I agree that you've done a great job with > this analysis. > > Has there been any progress since in terms of what can the "ignorant user" do > fic the problem? -Philip S Lingard In bug 472473 you mention that you are using PDF Writer 4.05. Comment #3 explains that PDF Writer is broken and in comment #4 Vlad agrees that implementing an awkward workaround that only partially fixes the problem is not the right solution. Is there any reason you can not use Distiller or one of the many free PDF writers such as PDF Creator that do work? For the case where other printers are printing garbled text, the things users can do to help is to help find a method of consistently reproducing this bug without requiring a specific printer (eg by printing to a free PDF creator instead). Currently some users always experience this bug while others such as myself have not been able to reproduce it (except the specific case in comment #37). If any one experiences this bug only some times (or with some websites) but at other times it does print correctly it would be helpful to try to identify any patterns in the cases where the bug occurs. For example in comment #37 I mention that my ability to reproduce the problem depended on the timing between when the page is loaded and when I printed it. I would be interested to know what additional fonts are installed on the systems that consistently reproduce this bug. I realize this is a difficult question to answer without access to another system with a freshly installed copy of Windows to compare it to. Note that even installing some printer drivers will install additional fonts.

Bug 473981, comment 1 has a minimal test case and PDF output. Selecting the font family 'MS Sans Serif' produces incorrect output. From the PDF it can be seen the the garbled output is in a bitmap font. The test case I created in comment 37 also reproduced the bug with a bitmap font.

(In reply to comment #45) > Bug 473981, comment 1 has a minimal test case and PDF output. > > Selecting the font family 'MS Sans Serif' produces incorrect output. From the > PDF it can be seen the the garbled output is in a bitmap font. The test case I > created in comment 37 also reproduced the bug with a bitmap font. I dont agree this necessarily is the same bug. But perhaps they are. When I print the samples in this bugreport (comment #37 and comment #20) I get the results described by others. It does not work on certain old drivers. But it works ok on most printers. The sample in my bugreport CAN NOT BE PRINTED ON ANY PRINTER as far as I can see. (Perhaps I just have to few printers.)

(In reply to comment #46) > I dont agree this necessarily is the same bug. But perhaps they are. [snip] > The sample in my bugreport... FWIW, this is regarding bug 473981, which was marked as a dupe in comment 44. henriko -- if you disagree about it being a duplicate, please comment on bug 473981, not on this one. (If every bug duped to this one had triggered a stream of comments here, this bug would be much longer and virtually unreadable. :))

Attachment is two page PDF scan of printout to Imagistics im4510 PCL6 printer. Posted because it may contain additional clues Page 1 - Garbled text for most of page, sidebar prints correctly Page 2 - Same website, switched to IE rendering using IE Tab plugin. Prints correctly. Version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6

PDF Writer works fine with Firefox 3 from Acrobat 8 Standard in Vista (32bit) Home Premium

This patch is a first attempt at making cairo print using unicode characters instead of glyph indices where possible similar to what IE does. This should fix the problems with printing to Adobe PDF Writer 5 and generic text printers (bug 452247). I have not tested with PDF Writer and while printing to the generic text printer works with my own test code, in mozilla-central I get an assertion (bad width : 'Not Reached' .../layout/generic/nsLineLayout.cpp line 182). When printing to PDF Creator with this patch the standard Type 1 fonts are not embedded so I expect PDF Writer 5 should work. I don't have any idea what is causing the incorrect font glyphs for other printers. My guess is that it is something to do with printer font substitution. If this is the case then this patch should fix that bug as well. There must be a reason why IE is going to the extra effort of printing as unicode where possible with fallback to using glyph indices.

I've tested the patch in Comment 50 with Adobe PDF Writer 5 and it works. It fixes the regression and produces output the same as IE. It would be interesting to get some feedback on whether this patch fixes the printing problems with other printers.

Is there any windows compiled version of Firefox with patch in Comment 50 ? I could send it to some of my customers having problem printing.

I have been able to reproduce the incorrect font glyphs problem with TrueType fonts on a Windows 2000 machine with a HP LaserJet driver installed from the HP CD that came with the printer (ie it is an old version of the printer driver). Further testing has revealed that this is very similar to the bug in PDF Writer 5. The printer driver seems to ignore ETO_GLYPH_INDEX. All latin text in Courier New/Arial/Times New Roman is garbled. Other fonts and non latin characters print correctly. Calling ExtTextOutW with unicode characters instead of glyph indices works either with or without ETO_GLYPH_INDEX set. I could also reproduce this problem on the Win 2000 machine directly with a cairo test case. Testing with the patch in comment 50 fixed the problem.

I am more than willing to test the patch from comment 50 against my office's Xerox WorkCentre Pro 423 if someone would either send me a build with the patch or point me in the direction of a tutorial/guide on how to patch and build Firefox on Windows. (I have built from source and very rarely applied a patch to source code on Linux, but have no experience doing the same on Windows.) Please feel free to contact me if you feel I could be of any help in getting this bug fixed.

Build documentation for every platform can be found here: https://developer.mozilla.org/En/Build_Documentation About patching, you can find that on MDC as well, but for your convenience, this should work: patch -p1 -u -i <absolute path to patch file> or you can use mq ( https://developer.mozilla.org/En/Mercurial_Queues ) and just drop it in .hg/patches, then you would simply do: hg qimport -e <name of patch file> hq qpush <name of patch file> Hope that helps.

(In reply to comment #60) > Build documentation for every platform can be found here: For getting bug-watchers to test, it's easiest to just use Mozilla's try-server to automatically generate builds for each platform: http://wiki.mozilla.org/index.php?title=Build:TryServer I've just pushed a build with up-to-date mozilla-central + Adrian's posted patch (attachment 374899 [details] [diff] [review]) to the try-server. Assuming that succeeds, builds will appear (for each platform, as they complete) in the next few hours, at this URL in a folder labeled "dholbert-try-b4a91c57b0ec": https://build.mozilla.org/tryserver-builds/?C=M;O=D

I gave Mr. Holbert's try-server build a test run and still had the same printing issues on my Xerox WorkCentre Pro 423. To double check that I had not messed something up, I uninstalled ALL the Firefox versions on my test computer, uninstalled the printer, and reinstalled the patched Minefield build and the printer (using the latest drivers off of Xerox's site) to no avail. I have a scan of my output, but it is identical to the this bug's first attachment so I figured that I would hold off uploading it unless someone thinks that it will be helpful. Can someone who has had some success printing with a patched build they made please test the build from the try-server to verify that the server applied the patch to it properly? Many thanks for everyone's work/help on this. Let me know if there is any other testing I can do or debug output I can provide.

Link to completed tryserver builds: https://build.mozilla.org/tryserver-builds/2009-05-08_10:09-dholbert@mozilla.com-try-b4a91c57b0e/

I tested the tryserver build in comment #63 with PDF Writer 5 and the HP LaserJet 4050 PS driver on Windows 2000 and can confirm the build contains my patch and fixes the printing for these two cases. I installed the Xerox WorkCentre Pro 423 PCL driver for XP from http://www.support.xerox.com/go/results.asp?Xtype=download&prodID=WCP_423DC&Xlang=en_US&Xcntry=USA and set the port to my LaserJet 4050. Printing works fine with IE. I can reproduce the garbled text problem with FF3. The tryserver build in comment #63 did not correct the problem. Going into the printer properties and clearing the "Use Printer TrueType fonts" checkbox fixes the printing. The garbled text occurs with fonts that are built into the printer like "Times New Roman" but prints fine with fonts like Verdana. It appears to be a problem with device font substitution. Running a mozilla-central debug build I am getting the following error when printing Times New Roman to this printer: WARNING: Uniscribe refuses to shape with given font: file d:/mozilla/mozilla-central/ff-dbg/gfx/thebes/src/../../../../gfx/thebes/src/gfxWindowsFonts.cpp, line 1814 due to the fNoGlyphIndex being set by ScriptShape(). According to http://msdn.microsoft.com/en-us/library/dd368797(VS.85).aspx this occurs with bitmap, vector, and device fonts. It looks like when fNoGlyphIndex is set, ExtTextOut should be called without setting the ETO_GLYPH_INDEX flag. I can not see any way for cairo to know when a device font has been substituted. Maybe the cairo_win32_surface needs an API function to switch between glyph indexing and unicode for cairo_show_glyphs().

Seeing as the last try-server build (from comment 63) has now disappeared, I've made a new build, again based off of current mozilla-central trunk with Adrian's patch applied (attachment 374899 [details] [diff] [review]). https://build.mozilla.org/tryserver-builds/dholbert@mozilla.com-try-7af6f83424e/try-7af6f83424e-win32.zip I'm mirroring this build on people.mozilla.org, so that testers can still use it after the try-server-hosted version gets taken down in a few weeks. The mirror link is: http://people.mozilla.org/~dholbert/builds/bug454532/try-7af6f83424e-win32.zip The MD5sum for this zip file is: 40d34375c36185a204b765b5787dc2db

(In reply to comment #65) > I'm mirroring this build on people.mozilla.org, so that testers can still use > it after the try-server-hosted version gets taken down in a few weeks. The > mirror link is: > http://people.mozilla.org/~dholbert/builds/bug454532/try-7af6f83424e-win32.zip This should fix the printing issues with PDFWriter and certain old print drivers that do not support ETO_GLYPH_INDEX. The other remaining problem is with device font substitution by some printer drivers as diagnosed in comment 64. Do any of the Mozilla developers have any ideas on how this could be fixed?

(In reply to comment #66) > (In reply to comment #65) > > I'm mirroring this build on people.mozilla.org, so that testers can still use > > it after the try-server-hosted version gets taken down in a few weeks. The > > mirror link is: > > http://people.mozilla.org/~dholbert/builds/bug454532/try-7af6f83424e-win32.zip > > This should fix the printing issues with PDFWriter and certain old print > drivers that do not support ETO_GLYPH_INDEX. I reinstalled my old Brother Laser HL-1060, tested both with the above build and Firefox 3.0.11. On your build, the problem seems to be partially fixed, but not completely though: The page contents prints now perfectly, but the standard header and footer outputs garbled text. As before, 3.0.11 outputs a completely blank page (which is normal since your patch is not included). My printer settings: Truetype mode: Download as Bitmap/Use Printer Truetype fonts. Let me know if you need further information...

It seems obvious to me, that this problem occurs with bitmapped (raster) fonts on Windows. Courier New (ttf) is fine, Courier (fon) is not. It's a major problem if a webpage (or e-mail) specifies Courier as the default font. I've even seen a greasemonkey script to replace Courier with Courier New! Actually that's probably the best solution right now, which is sad. At a minimum perhaps the print routine should just convert the Courier to Courier New transparently (while leaving Courier on the rendered page). This would have minimum impact while making printouts at least legible... -Dan

No reports from sumo in about a month or so.

(In reply to comment #69) > No reports from sumo in about a month or so. You aren't looking hard enough for those reports. I am still seeing 2 or 3 reports per week of this issue. Is there any way of "fixing" this issue with a Greasemonkey script or with some userChrome.js script? I am starting to get the impression that this Bug is never gonna be fixed, just like the Bugs related to printing only the first page of multiple pages has never gotten fixed.

(In reply to comment #64) > clearing the "Use Printer TrueType fonts" checkbox fixes the printing. It does NOT fix the problem that I have printing non-HTML webmails (at least on my Earthlink account - maybe not on Gmail). (These are emails formatted for printing, not the whole webmail screen displaying the email and all HTML graphics and buttons. The whole page prints fine. When I use webmail's "print" feature to reformat the emails, I can tell from the look of the body text font (like a Courier rendered on really low-res monitor or printer) which pages will not print.) I have the problem equally on Brother HL-5250 and Sharp AR-M550N PCL6. For the Brother, in manual setting, the TrueType checkbox was and remains clear, and the headers continue to print fine while body of email is garbage. On the Sharp I changed setting from "Resident Fonts, Download as TrueType" to "Download Fonts." It doesn't matter if I choose "Download as bitmap" or "Download as TrueType." If I use "Adobe PDF" printer (via Acrobat 8.1 professional), the email headers are clean Arial, but the body looks bad; it is marginally readable, resembling Courier, but the character spacing is very erratic and the ascenders and descenders (and tops of uppercase letters) are cut off.

Agreed, this bug is easily reproducible on any Windows computer. Do we need more bug reports to fix it? ed, here is my greasemonkey script, which drops Courier for Courier New: ----------------- // ==UserScript== // @name Fix Courier Bug // @namespace http://userscripts.org // @description Replaces "Courier" with "Courier New" font // @include * // @author Dan // ==/UserScript== var elementList = document.getElementsByTagName('*'); for (var i = elementList.length - 1; i >= 0; i--) { var elementItem = elementList[i]; var ff = getComputedStyle(elementItem, '').fontFamily; if (ff=='Courier') { var oldff=ff; ff = ff.replace('Courier New', '1234567890qwertyFONT'); ff = ff.replace('Courier', 'Courier New'); ff = ff.replace('1234567890qwertyFONT','Courier New'); elementItem.style.fontFamily = ff; alert(elementItem.style); } } -------------------

Sorry, wrong version of that script: -------- // ==UserScript== // @name Fix Courier Bug // @namespace http://userscripts.org // @description Replaces "Courier" with "Courier New" font // @include * // @author Dan // ==/UserScript== var elementList = document.getElementsByTagName('*'); for (var i = elementList.length - 1; i >= 0; i--) { var elementItem = elementList[i]; var ff = getComputedStyle(elementItem, '').fontFamily; var oldff=ff; ff = ff.replace('Courier New', '1234567890qwertyFONT'); ff = ff.replace('Courier', 'Courier New'); ff = ff.replace('1234567890qwertyFONT','Courier New'); elementItem.style.fontFamily = ff; } ------

There appears to be 4 different bugs that result in all these bug reports. 1) Print driver does not support ETO_GLYH_INDEX Some old printer drivers, eg PDFWriter 5 and LaserJet 4050 PS on Win2000, do not work with ETO_GLYPH_INDEX. Comment 50 has a patch for this. It won't work for complex text but it does provide equivalent functionality to IE as described in comment 3. Vlad, should I push this patch to cairo? 2) Uniscribe says no to ETO_GLYPH_INDEX If ScriptShape() sets fNoGlyphIndex, ETO_GLYPH_INDEX must not be used with ExtTextOut as ScriptShape() has returned unicode characters instead of glyph indices (comment 64). This occurs with bitmap, Type 1, and device fonts. This is the cause of bug reports where printing with a font like "Times New Roman" produces garbled output but printing with "Verdana" works fine. The print driver forces subsitution of the fonts that are available in the printer (such as Times Roman). As Windows knows a device font is used it sets fNoGlyphIndex since the glyph indices of the Times New Roman font on windows are not going to be the same as the glyph indices on the font in the printer. Cairo already has a workaround for Type 1 fonts to map glyph indices back to unicode and call ExtTextOut with ETO_GLYPH_INDEX. I am unable to provide a workaround in cairo for TrueType fonts since without additional API it is not possible to determine within cairo if fNoGlyphIndex has been specified. 3) Firefox selects "courier.fon" bitmap font when "Courier" font requested This causes two problems. It triggers the fNoGlyphIndex problem above. It also results in ugly output on the screen and the printer. On many printers drivers this font is substituted with the Courier font on the printer. This gives nice results when printing but the problem for cairo is that for this to correctly work the glyph metrics need to be obtained using the printer DC. However cairo always uses the screen DC (CreateCompatibleDC (NULL) in cairo-win32-font.c) to get the metrics. Due to the incorrect metrics the workaround implemented in cairo is to print a fallback image of the bitmap font. The easiest fix for this problem would be to select "Courier New" when "Courier" is requested. I can not see any benefit in selecting the bitmap version. It does not scale correctly and just looks ugly. 4) Printing to text mode printers is broken Another regression since FF2 is the inability to print to text mode printers (bug 452247). This affects printing to the "Generic / Text Only" printer driver as well as other special devices. This appears to be caused by a combination of 2) and 3). Enumerating all fonts on the DC of the "Generic / Text Only" printer driver results in: "Device Font 10cpi" "Device Font 12cpi" "Device Font 17cpi" As the only fonts available are the device fonts, 2) needs to be fixed to get the correct characters. I did some testing with cairo. After ensuring ETO_GLYPH_INDEX is not used, the characters were correct but the spacing was wrong. eg "The qui ck brown fox jum ps over". As the generic text only printer (and probably other text only printers) only prints characters at fixed positions, the driver is mapping the x,y coordinate of each character in ExtTextOut to the nearest character position. If the glyph metrics are not accurate (due to using the screen DC instead of printer DC) random spaces are inserted. A possible hack to fix the glyph metrics problem is to use GetDeviceCaps() to check if the device type is DT_CHARSTREAM (and maybe also check that text is not scalable) and call TextOutW instead of ExtTextOutW for strings of characters with the same y coordinate.

The byte codes displayed on my printer appear off by 0x1d in Seamonkey 2.0 and in Firefox 3.5.5. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 I get a repeatable pattern on my Brother HL-1440 when I attempt to print a text file from my hard disk. Comparing the hex values of the garbled text to the text I was attempting to print, the bytes that were printing were consistently 0x1d (29 decimal) less than the value that I was attempting to print. Example: Hook (Sent to printer) +RRN (Printed) Preferences->Appearance->Fonts: System (Size 16) Preferences->Appearance->Allow documents to use other fonts: Unchecked Microsoft Windows 2000 [Version 5.00.2195] Service Pack 4 Loading the latest release version of Firefox: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 went from an earlier version that would print a header and footer for a text page to a version that will print neither. After testing several fonts, found that setting Tools->Options->Content->Default Font: to WST_Engl would cause headers and footers to print. And setting: Tools->Options->Content->Default Font ... Advanced->Monospace: to WST_Engl would print the same exact garbled (translated by 0x1d) characters I saw in Seamonkey. That is a pretty definite pattern. Hope this helped.

I get this problem with my HP LaserJet 4000, printing with PCL5e under Firefox 3.5.x on a Windows XP Pro, SP3, system. I cannot print at all with PCL6. I tried the print preview trick, and it seems to work, at least with some web pages. Not a very satisfactory solution.

I will confirm this problem with PrimoPDF 5.0.0.19

I will confirm this problem with PrimoPDF 5.0.0.19 on Windows 7. In my instance it happened only to the bold text on the web page I was printing.

Won't block the release on this -- sadly, it's nothing new -- but we should look at the patch here and/or figure out what to do.

Update to the latest cairo trunk

I made a try server build with this patch: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-0a1a9ecac937/tryserver-win32/ If those having printing problems could test it out that would be great.

jrmuizel, based on comment 50, I'm guessing your patch should also help with bug 452247 (blank pages from generic text printers). Would you mind generating another TryServer build for testing (since the one in comment 82 has expired), and mentioning it on that bug, too? That bug has gotten more recent activity from users who can reproduce it, so you may be more likely to get feedback over there.

I've committed the patch in comment 81 to cairo master. This fixes the first bug identified in comment 75. I've done some more analysis and testing of the device font issue (2nd bug in comment 75). This problem only occurs when using the printer DC with ScriptShape() or GetGlyphIndices(). If I use the display DC, both ScriptShape() and GetGlyphIndices() returns the correct glyph indices and printing with ETO_GLYPH_INDEX works. I have also tested Firefox 4 beta and the problem has been fixed. Comparing the Firefox 3 and Firefox 4 source it looks like Firefox 3 is using the printer DC in the windows font code while Firefox 4 is using the display DC. I am attaching a patch that fixes the bitmap courier font issue (3rd bug in comment 75). The problem here is on a standard windows install there is a bitmap courier font that firefox uses when "Courier" is requested. It looks ugly, and does not scale well or print correctly. As Windows already comes with the TrueType font "Courier New" that is identical in appearance to courier it is preferable to use Courier New instead of the bitmap courier unless the user has installed another font named Courier or configured a font substitution for "Courier" in the registry. The attached patch will substitute "Courier" with "Courier New" if there is not already a substitution for "Courier" in the registry and there is not already another font named "Courier" that is at least as good as the Courier New font (ie is TrueType or OpenType). The font type preference list has been changed to move Type1 below TrueType/OpenType fonts. I see no reason why legacy Type1 fonts were preferenced higher that TrueType fonts. Type 1 fonts don't display as nicely as TrueType, are limited to 256 characters, and they do not have the advanced font features of TrueType/OpenType fonts. As far as I can tell these three changes (the cairo fix, update to firefox 4, and the courier font patch) fix all cases where font glyphs are incorrectly printed. The fourth bug in comment 75 (text mode printer problem) has a separate bug (Bug 452247). I do not know of any easy way to fix this.

It seems the try server web interface is not working so I can't create a tryserver build. It would be good if someone with push access can create a tryserver build of mozilla-central with these two patches: https://bugzilla.mozilla.org/attachment.cgi?id=457365 https://bugzilla.mozilla.org/attachment.cgi?id=490867

Thanks, Adrian. A tryserver build should show up here in a few hours: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/ktomlinson@mozilla.com-435102d82b2e Tryserver needs level 1 commit access now. https://wiki.mozilla.org/Build:TryServer#Try_Server I can vouch for you, Adrian, if you'd like to apply.

Comment on attachment 457365 [details] [diff] [review] Patch to make cairo print as unicode where possible v2 >@@ -1501,7 +1501,8 @@ _cairo_win32_surface_show_glyphs (void *surface, >+_cairo_win32_surface_show_glyphs (void *surface, >+ cairo_operator_t op, >+ const cairo_pattern_t *source, >+ cairo_glyph_t *glyphs, >+ int num_glyphs, >+ cairo_scaled_font_t *scaled_font, >+ int *remaining_glyphs, >+ cairo_rectangle_int_t *extents) >+{ >+ return _cairo_win32_surface_show_glyphs_internal (surface, Perhaps this patch didn't get through a rebase so well? e:/builds/moz2_slave/tryserver-win32/build/gfx/cairo/cairo/src/cairo-win32-surface.c(1760) : error C2084: function 'cairo_int_status_t _cairo_win32_surface_show_glyphs(void *,cairo_operator_t,const cairo_pattern_t *,cairo_glyph_t *,int,cairo_scaled_font_t *,cairo_clip_t *,int *,cairo_bool_t)' already has a body e:\builds\moz2_slave\tryserver-win32\build\gfx\cairo\cairo\src\cairo-win32-private.h(173) : see previous definition of '_cairo_win32_surface_show_glyphs'

Attached is the version of the print as unicode patch I've been using in local repo.

Tryserver build with attachments 492295 and 490867 here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/ktomlinson@mozilla.com-565886bbd3f5/tryserver-win32/

Has anyone had the opportunity to try out the try build in comment 89? This should fix both the problems printing Courier fonts and garbled characters.

I've put a new build up at: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmuizelaar@mozilla.com-732893fd2c86

Hi, the build links have expired. Are there plans to fix this soon? I took a look at the Firefox 4 RC and the issue is present there as well.

(In reply to comment #89) > Tryserver build with attachments 492295 and 490867 here: (FWIW, those attachments don't apply cleanly anymore -- each of them fails 1 hunk, even when applied with 'patch -F10'.)

Rebased substitute courier font patch

Rebased print as unicode patch

The problem remains in Fx 4.0.1, Fx 5.0(latest?b2), Seamonkey 2.1.b3.

(In reply to comment #97) > The problem remains in Fx 4.0.1, Fx 5.0(latest?b2), Seamonkey 2.1.b3. I have printing with a Cannon IP1300 pixma with the latest printer drivers

Confirmed problem remains in Firefox 4.0.1 (client details: XP SP3, 32-bit; Canon PIXMA MX860 with latest drivers, and have performed numerous bare-metal reinstalls/clean installs to no avail). Printer is a highly-rated AIO printer for consumers, with added features like Ethernet and 802.11: http://www.usa.canon.com/cusa/consumer/products/printers_multifunction/office_all_in_one_inkjet_printers/pixma_mx860 I can put up photos of what the printed results look like if requested. Text appears visible but is horribly spaced. Adobe PDF in-browser printing isn't relevant here (I'm printing stock HTML-based web pages, and I turn off Adobe's in-browser **** anyway). What will it take for this to get fixed? How can the user community help? I think most of us are willing to try debug builds, but we need indication someone is actively working on this and thus provides said builds. I'm willing to go even further by putting my money where my mouth is -- if a developer wants a Canon PIXMA MX860 printer so they can work more reliably on this issue, contact me + set up an Amazon Wishlist and I'll buy you one which you can keep indefinitely. Yup, really. Getting this fixed is easily worth ~US$230. AFAIK, the only workaround is to use Print Preview first, then click Print from there; otherwise use another browser.

Rebase print as unicode patch

Rebase substitute courier patch

Rebase print as unicode patch

(In reply to comment #99) > What will it take for this to get fixed? How can the user community help? > I think most of us are willing to try debug builds, but we need indication > someone is actively working on this and thus provides said builds. I've rebased my patches for this bug. It needs someone from mozilla to create a test build using these patches.

(In reply to comment #103) > It needs someone from mozilla to > create a test build using these patches. Triggered: http://tbpl.mozilla.org/?tree=Try&rev=8d2312a235e8 Builds will be appearing here (currently 404), once they complete: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dholbert@mozilla.com-8d2312a235e8

(That build is based off of today's mozilla-central trunk, btw. For maximum safety, it's best (though not strictly necessary) to create a new Firefox profile before using the above build, to avoid getting a confused profile from mixing Firefox versions.) http://support.mozilla.com/en-US/kb/Managing-profiles#w_creating-a-profile

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dholbert@mozilla.com-8d2312a235e8 returns HTTP 404. $ curl -i -s -S 'http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/dholbert@mozilla.com-8d2312a235e8' HTTP/1.1 404 Not Found Server: Apache X-Backend-Server: ftp2 Content-Type: text/html; charset=iso-8859-1 Date: Wed, 20 Jul 2011 00:32:33 GMT Accept-Ranges: bytes Connection: Keep-Alive X-Cache-Info: caching Content-Length: 266

We should really put the builds in a more permanent place...

Yeah, TryServer builds are auto-deleted after a few days (a week?) now, I think. Jeremy (and others who can reproduce & are willing to try a test build): hold on, and I'll make another build and post it in a more permanent spot ASAP.

Thanks guys. Also, I'm not familiar with Mozilla tags, so when you say "trunk" I'm not sure if you're referring to a 5.x trunk build or trunk as in 6.x or 7.x.

Trunk is actually at 8.x these days :-)

You can get the builds from: http://people.mozilla.com/~jmuizelaar/print-test/

(In reply to comment #111) > You can get the builds from: > http://people.mozilla.com/~jmuizelaar/print-test/ I have proved Nightly 8.0a1 (2011-07-19)and the bug 452247 even continues

Can others give this a try and report their results?

Jeff, I will need to dedicate some time to setting up a Windows XP VM to test this. I do not want to risk messing up my existing workstation's Mozilla configuration (registry settings, as well as the profile (yes I know it can be backed up), etc.) given that the test builds are 8.x when I'm using 5.x on my workstation. A VM should allow me to do testing without any repercussions, using the same printer drivers as I use normally. I will try to get this set up tonight.

(In reply to comment #112) > > I have proved Nightly 8.0a1 (2011-07-19)and the bug 452247 even continues Bug 452247 is issue 4 in comment 75 and is the hardest to fix. See also comment 84 where I explain that bug 452247 is a separate bug and not addressed by my patches.

Spent time getting the VM set up (stock XP SP3) and installed Jeff's 8.0a1 nightly build. I printed the following two web pages in both the VM (Firefox 8.0a1) and the native XP SP3 host (Firefox 5.0): 1) http://www.w3.org/Style/Examples/007/fonts 2) http://www.amazon.com/gp/orc/rml/D6xSgsP8RRMA (Note: not sure if #2 will work for others; it's an Amazon Return Shipment page, so it may be tied to my Amazon authentication cookie) Based on what I can tell, 8.0a1 fixes the problem with the stock Courier font showing up as gobbledegook, as well as what appears to be some sort of glyph + Unicode issue (UTF8 vs. UTF16 byte encoding assumption?). I've scanned the resulting prints and labelled each so folks can see the difference for themselves. http://www.malkavian.com/~jdc/firefox_454532/ I can't say for certain 8.0a1 fixes all the problems outlined in this bug, but it fixes the above two issues, obviously. Can the(se) fix(es) be backported to Firefox 5.x? :-)

(In reply to comment #116) > I can't say for certain 8.0a1 fixes all the problems outlined in this bug, > but it fixes the above two issues, obviously. Great. I'll try to get this stuff landed soon. > Can the(se) fix(es) be backported to Firefox 5.x? :-) Unfortunately, this doesn't meet the criteria for 5. You'll have to wait for 8.0.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #117) > > Great. I'll try to get this stuff landed soon. Any progress on getting these patches landed?

(In reply to Adrian Johnson from comment #118) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #117) > > > > Great. I'll try to get this stuff landed soon. > > Any progress on getting these patches landed? Sorry, I dropped the ball and forgot to get this stuff landed. I've landed the cairo patch on inbound and I'll try to find someone to review the other patch.

This bug is resolved fixed, but there is an unreviewed and not checked in patch. Reopen or file a new bug?

I guess this patch got lot in jdagget's review queue. John, could you review the patch?

Comment on attachment 541030 [details] [diff] [review] Substitue courier with courier new (In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #122) > I guess this patch got lot in jdagget's review queue. John, could you review > the patch? Nope, it didn't get lost I was looking at this yesterday. One thing I'm wondering about here is why we end up using Courier at all. If Courier is being used as a default style within the browser, that's where we should be doing this substitution. I can see several instances of Courier in the font prefs (all.js) that should probably be trimmed. *If* the problem is that Courier is specified in content (rather than some default internal to the browser), then the current patch only applies the Courier ==> Courier New substitution within the GDI font list code, it also needs to apply this in the DirectWrite font list code. + gfxFontFamily *ff; + nsAutoString substituteName; + nsAutoString actualFontName; + substituteName.AssignLiteral("Courier"); + actualFontName.AssignLiteral("Courier New"); + BuildKeyNameFromFontName(substituteName); + BuildKeyNameFromFontName(actualFontName); + if (!mFontSubstitutes.Get(substituteName)) { + PRBool substitute_courier = PR_TRUE; + ff = mFontFamilies.GetWeak(substituteName); + ff->FindStyleVariations(); + nsTArray<nsRefPtr<gfxFontEntry> >& fontList = ff->GetFontList(); + for (PRUint32 i = 0; i < fontList.Length(); i++) { + GDIFontEntry *fe = static_cast<GDIFontEntry*>(fontList[i].get()); + if (fe->mFontType >= GFX_FONT_TYPE_TRUETYPE) { + substitute_courier = PR_FALSE; + break; + } + } + if (substitute_courier && (ff = mFontFamilies.GetWeak(actualFontName))) { + mFontSubstitutes.Put(substituteName, ff); + } + } 1. I don't think the logic to check for a TrueType version of Courier is necessary. If no substitute for Courier exists in the registry, stick in Courier New as the substitute and be done with it. 2. Define the 'actualFontName' within the block for the 'substitute_courier' conditional, no need to muck about with it until necessary. Picky, I know, but this is code along the startup path so we should be careful about little things.

> * This list is sorted in order from least prefered to most prefered. > - * We prefer Type1 fonts over OpenType fonts to avoid falling back to > - * things like Arial (opentype) when you ask for Helvetica (type1) > **/ > enum gfxWindowsFontType { > GFX_FONT_TYPE_UNKNOWN = 0, > GFX_FONT_TYPE_DEVICE, > GFX_FONT_TYPE_RASTER, > + GFX_FONT_TYPE_TYPE1, > GFX_FONT_TYPE_TRUETYPE, > GFX_FONT_TYPE_PS_OPENTYPE, > - GFX_FONT_TYPE_TT_OPENTYPE, > - GFX_FONT_TYPE_TYPE1 > + GFX_FONT_TYPE_TT_OPENTYPE This doesn't seem necessary. If there's a strong reason to do this, fine, but this seems like it could have unexpected consequences.

Yes the problem is courier is specified in content. I've updated the patch to remove to check for a TrueType version of courier. gfxDWriteFontList.cpp already substitutes courier with courier new because DirectWrite does not support bitmap fonts.

Non-coder here, chiming in in the hope that my case might be useful. Misprinting glyphs suddenly appeared on one computer, driving one printer somewhere recently in the FF6-7 timeframe. Computer, printer: Win7-32 driving a Brother HL-1440 via network. This is an older PCL6 laser. Printer is attached to an XP machine via USB and shared. Printout appearance: All fonts print total garbage, with lots of light print and voids, size approx 5 pts. Headers, footers and graphics appear normal and are (approx) properly placed, with the jpgs floating elegantly in mid-garbage. All font faces are affected, not just Courier/monospaced. FF 7.01 Prints fine to all other printers, **including to a Brother MFC, also oldish, also PCL!!!* FF 7.01 prints find to THIS Printer from its XP host machine and from a Win7-64 machine. Reinstalling FF with complete profile removal (Revo and manual registry search) had no effect. Removing and reinstalling the printer driver had no effect. There is no choice for this printer; you get the one WDM driver extant from Microsoft, which is a (32-bit) wonder from 2002, originally for XP and Win 2k! IE9 and Chrome of course print properly to this printer.

No NS_NAMED_LITERAL_STRING?

This is labelled as RESOLVED/FIXED. However, comment #117 stated that I should expect the issue to be fixed in 8.0. Well, I'm running 8.0 now, and attached is a scan of a print-out of Page 1 of the following web page: http://www.dslreports.com/forum/r26464740-gogoc-using-100-of-CPU0 The "Print Preview, then Print" workaround, thankfully, still works. So, how is this RESOLVED/FIXED exactly? What else do developers need at this point? As I said in earlier comments, I will go to great lengths to help out in any way I can.

Great, Bugzilla turned my URL into some kind of auto-svn/git revision link thing. Beautiful. Here's the tinyURL version to it (just have to trust me): http://tinyurl.com/8339dza

(In reply to Jeremy Chadwick from comment #130) > Created attachment 573161 [details] > Firefox 8.0, Canon PIXMA MX860, XP SP3 > > This is labelled as RESOLVED/FIXED. However, comment #117 stated that I > should expect the issue to be fixed in 8.0. Well, I'm running 8.0 now, and > attached is a scan of a print-out of Page 1 of the following web page: > > r26464740-gogoc-using-100-of-CPU0">http://www.dslreports.com/forum/r26464740- > gogoc-using-100-of-CPU0 > > The "Print Preview, then Print" workaround, thankfully, still works. > > So, how is this RESOLVED/FIXED exactly? What else do developers need at > this point? As I said in earlier comments, I will go to great lengths to > help out in any way I can. The first of these patches in FF9, the Courier patch is in FF10.

Upgraded to Firefox 9.0 today. No improvement compared to Firefox 8.0 (see previous attachment of mine, comment 130). The fonts being shown on these pages/attachments *are not* Courier. As such, I'd like to propose this be reopened from RESOLVED/FIXED status.

Jeremy, could you please file a new bug for this and mention the bug number in this bug? There are already more than enough comments in this bug, so it's better to start working in a new bug, that makes things less confusing.

I'm not sure that really makes things "less confusing" (trust me, we use Bugzilla at work (your offices used to be next to ours :-) ) and we run into this behaviour all the time). I'll do that if I'm told to by John Daggett at Mozilla Japan, who I am working with out-of-bug to try and diagnose this situation. I'll keep folks posted as things progress. In the interim, I would really appreciate it if one of the 9 zillion users CC'd on this bug would please chime in and state if Firefox 9.0 has at all resolved the bug for them. So far I seem to be the only one adamant about getting this fixed, and it's been proven that the more user community members who participate/comment on a bug, the more serious Mozilla takes it. Let's all work together!

The scan in comment 130 looks to be a different bug since the glyphs are correct but are widely spaced. This bug is about cases where the font glyphs are the wrong characters. I can't reproduce the problem in comment 130. After opening a new bug it would be helpful if you could try the following: - try a different printer and/or print drivers - try a pdf printer (eg PDFCreator)

The problems shown in comment 130 and comment 133 appear to be something mysterious/odd. I just installed a fresh XP instance under VMware Workstation 8, and printed out results of http://tinyurl.com/8339dza for Firefox 3.6.25, Firefox 4.0.1, Firefox 5.0.1, Firefox 6.0, Firefox 7.0.1, and Firefox 8.0.1 -- all of which look fine, *except* 3.6.25 which prints the first code section block then stops (but I'm not worried about that). All subsequent versions print things looking fine. I can scan all the results and upload them somewhere online if someone is curious, but they all look identical sans 3.6.25. I'm therefore left thinking there is something on my main host XP system that is causing this problem. Gut feeling says it's a font of some sort (though I rarely install any fonts). Looks like it's time to troubleshoot monotonously until I figure out what the root cause is.

Root cause of comment 130 and comment 133 found -- setting "gfx.font_rendering.harfbuzz.scripts = 0" causes this problem, and I can reproduce it on our printers at work as well (HP LaserJet business-class). I'll search for existing bugs on this problem, or open a separate bug if I can't find any. What a waste of an afternoon...