Closed Bug 396315 Opened 15 years ago Closed 15 years ago

Type 1 and other fonts incorrectly displayed


(Core :: Graphics, defect, P2)

Windows XP





(Reporter: tkloos, Assigned: pavlov)





(13 files, 3 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091516 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091516 Minefield/3.0a8pre

Pages that request Adobe Type 1 fonts are not displayed correctly if the Type 1 font (like Helvetica) is installed on the computer.  See tinderbox_status.png for an example.  The page can be made readable by disabling "allow documents to use other fonts".  It appears that displayed text size may also be a factor.

Reproducible: Always

Steps to Reproduce:
1.  Display font_display_problem.html
2.  Observe output
Actual Results:  
See firefox_07091516.png or seamonkey_07091515.png.

Expected Results:  
See ie6.png or opera_9_23.png.

Note also the different appearance of the MS vectored fonts compared with the IE or Opera rendering.
Attached image Example of problem
Attached file test case
Attached image IE6 rendering
Attached image Opera rendering
For implementers that don't have access to Type 1 fonts, try this web site:

"cmr10" is located in a public zip file there.
Flags: blocking1.9?
Are you using Adobe Type Manager?  I don't know of any other way to get Type 1 fonts to work on Windows...
Two XP-Pro systems that exhibit the bug are *not* using ATM and one other is using "ATM-Light" (downloadable for free from Adobe).  Windows 2000 and newer have Type 1 display abilities built-in.  Simply install the *.pfm files through the control panel.
ok, should be pretty easy to fix -- i'll take a look
Assignee: nobody → pavlov
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
Attached patch part 1 [checked in] (obsolete) — Splinter Review
there are a few problems here.

First is that we don't do the right thing with type1 fonts when figuring out the cmap.  this also fixes a problem where we were treating a lot of unicode fonts as symbol fonts and not getting their full cmap out of the font.

Second is that it doesn't look like Uniscribe supports Type1 fonts properly and we have code in place now that causes them to go through the Unsicribe path and not the GDI/ExtTextOut one.  It is easy to remove that bit of code, but that breaks some other cases so I need to keep looking at the problem.
Attachment #285890 - Flags: review?(vladimir)
Ever confirmed: true
Comment on attachment 285890 [details] [diff] [review]
part 1 [checked in]

r=me, would prefer the flag to be called something other than mSymbolFont though since it's not only for symbol fonts any more (maybe mGDIOnlyFont?)
Attachment #285890 - Flags: review?(vladimir) → review+
Target Milestone: --- → mozilla1.9 M10
Comment on attachment 285890 [details] [diff] [review]
part 1 [checked in]

checked in this patch.. leaving open for rest of issues
Attachment #285890 - Attachment description: part 1 → part 1 [checked in]
Target Milestone: mozilla1.9 M10 → ---
Blocks: 403567
No longer blocks: 403567
Depends on: 403567
I've seen a related issue when printing (only) using Firefox 3.0b1 with bitmap fonts installed - see bug #405433.  Not sure if this is a duplicate of this bug, so I'll leave someone else to close #405433 as a duplicate if appropriate.
Duplicate of this bug: 366983
Duplicate of this bug: 404972
Duplicate of this bug: 408181
Pav is there more work here?
Duplicate of this bug: 404977
I just created bug 417310 which is a possible duplicate -- Type 1 fonts render as symbols for browser window elements, such as menus and dialog buttons.
Duplicate of this bug: 417310
Blocks: 417310
Bug 417310 no longer marked as a duplicate of this bug, see there for details.
070625 is the last time I know of that Type 1 fonts are displayed correctly.
070627 is broken.

Judging from the changes in that time frame and the bug comment text, I'd guess that the patches for bugs 324706 and/or 269723 might be related to this issue.
Priority: P4 → P2
Duplicate of this bug: 417310
Flags: tracking1.9+ → blocking1.9+
Duplicate of this bug: 420996
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030706 Minefield/3.0b5pre. With FF on the same PC everything looks fine.
Shouldn't this be flagged as Blocking 1.9a1+ so that it gets fixed soonest. Or am I not understanding the flagging and the blocking1.9 will take care of it. Cause this bug is not on the P1/P2 blocking list for Beta 5 - see referenced in the status meeting minutes.
its on my list, i'm working on it, hoping to have something soon -- i've got a hack that fixes it now but going to try some other things tomorrow.

blocking1.9a1 is for alpha 1 -- that ship has sailed.  it is set correctly
this forces type1 fonts to go through GDI rather than Uniscribe for text rendering.  They should render correctly but they're treated as symbol fonts so they won't do proper fallback until we write additional code to determine a character map for them.
Attachment #285890 - Attachment is obsolete: true
It's better (Helvetica and CMR10 are OK), but Courier is still broken, both in my test case and at
From front page of
There may be an "off by 1" error someplace.   Upper case Helvetica "A" seems to get munched.  See attachment id=309152, a snapshot from .
The Helvetica problem is weird.  With my patch we won't do font fallback if things are missing with Type1 fonts.  I'm going to see if we can get some kind of character map for them.
hm, Do you have any more tests with easy-to-find fonts?  I don't have a type1 helvetica.  I have a patch that might fix the problem if you can test.. will post it here in a sec.
Attached patch maybe fix? (obsolete) — Splinter Review
this seems to work with CMR at least as my default font.  we'll do proper font fallback for it.  I have no clue what will happen with Asian Type1 fonts.
I'm not sure what to do beyond this.
Attachment #309318 - Attachment is obsolete: true
Attachment #309319 - Flags: review?
Attached patch fixSplinter Review
this fixes the problem with 'A'
Attachment #309319 - Attachment is obsolete: true
Attachment #309519 - Flags: review?(vladimir)
Attachment #309319 - Flags: review?
thanks for the help tracking this down guys.  I think it should work OK now.  There might be some slight issues with non-latin-1 Type1 fonts but I'm going to cross my fingers that people aren't using those.
Closed: 15 years ago
Resolution: --- → FIXED
While somewhat less of a problem, the Type 1 font "Courier" (com_____.pfm) still appears broken, but works fine in IE and elsewhere.
Duplicate of this bug: 422925
Duplicate of this bug: 425162
As of the 2008032610 tinderbox, Courier (and other Type 1 fonts) look good.  However, somewhere along the line the MS bit mapped font spacing took a hit.  Fortunately, the usage of these in web pages is probably nil.
argh, can you file a new bug and toss this testcase in there?  I'll see what I can do....
New bug filed for MS bit-mapped fonts with same test case.  Bug 425336.
Good luck Stuart and thanks for the Type 1 fixes.
verified fixed using the testpage and other testsurls with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217

-> Verified fixed
The Type 1 fonts problem is only solved on screen display, not when printing!
Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv: Gecko/2008070208 Firefox/3.0.1
Example print with Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv: Gecko/2008070208 Firefox/3.0.1
This is not fixed. 

Add-ons: Ad-Block Plus (but these problems existed before installing this add-on.) on FF3:
on Safari:
Note the problems with the smaller font, specifically the a's and e's. on FF3:
on Safari:
Note the corruption is much more obvious.

Shrinking the font size below default in FF3 will get the Ubiquity site to display "correctly". Shrinking the font on the register site will never get the font to display cleanly, increasing the font size will get it to go to garbage characters like the Ubiquity site.

Uninstalling Helvetica from the Fonts folder will solve all of these problems.

These are not the only sites that display this behavior, the list is very lengthy if more examples are needed I can supply them. This is new behavior as of moving from FF2 to FF3, there were no problems prior to upgrading.
Blocks: 454532
You need to log in before you can comment on or make changes to this bug.