I can understand the reasoning behing Mozilla's behavior of displaying text in Arial, Times New Roman, or Courier New-- all Monotype fonts included with Windows-- when the font face or style sheet specifies Helvetica, Times or Courier, respectively. After all, most people only have the former set of fonts and not the latter on their systems. Some users (such as myself), however, *do* have Adobe's versions of Helvetica, Times and Courier installed on our machines. There's no need for this font substitution; in fact, the resulting rendering is actually somewhat inaccurate! (Internet Explorer, incidentally, correctly uses the Adobe fonts rather than their Monotype equivalents when they're specified.) Is there any way to have Mozilla check whether an actual Helvetica, Times or Courier font exists on the system before substituting their Monotype equivalents?

Is there an HTML testcase that demonstrates this problem?

Yes: http://home.c2i.net/dark/linux.html The <i>font-family</i> in the style sheet is defined as <i>helvetica,arial,sans-serif</i> -- but the PostScript Helvetica that's on my system is not being used to display the page.

Erm, oops. Ignore the attempted HTML codes in the comment post. ;-)

Does this testcase demonstrate the problem too?

This is actually Arial, not the true Helvetica.

This is Adobe Helvetica.

Yes, Boris, attachment 84080 [details] shows all four lines as being in the same font (which, of course, is Arial).

This one for Times and Courier.

To intl. This worksforme on Linux (Adobe and Monotype fonts exactly as described), so sounds like this is Windows-specific.

I am not sure if this is Windows specific. As far as I know the font mechanism is cross-platform. assign to shanjian for his insight.

The difference in the rendering is slight, but it's nonetheless there.

Is there a place that I can download a helvetica PS font? Do I need to install some kind of font engine to utilize this font? Or codeman38, could you help me to verify a patch? (ie. make a build and try it in your environment).

Shanjian, what OS are you using? If 95/98/ME/NT4, you'll have to install Adobe Type Manager to use the postscript fonts. http://www.adobe.com/products/atmlight/main.html The Helvetica postscript fonts are installed with Adobe Acrobat Reader 3.0 (but were, ironically enough, substituted with Arial in newer versions!); they're also available on various websites, such as http://filebox.vt.edu/eng/ece/tront/disk2/psfonts/ Download hv*.pfb and hv*.pfm and install them using ATM or the fonts control panel.

Arial and Helvetica looks very similar. Helvetica does not looks as good as Arial. So codeman38, is there any practical reason except pure technical correctness?

No, other than technical correctness, there's no real reason. Perhaps there should be an option in prefs.js to let the user choose their preferred method of rendering Helvetica/Times/Courier? It could be set to use the substitutions by default, but if a user wanted the "true" Adobe fonts, they could easily change that option.

that is an option, but we must have practical reason to justify the action. I will resolve this bug as wontfix. Feel free to reopen this bug when such kind of situation arises.

> Helvetica does not looks as good as Arial How can we make this blanket statement if we don't know _which_ Arial and Helvetica are involved??

Mark as verified as wontfix. Please re-open if disagree.

Reopening because I discovered this substitution is actually HARD-CODED into the Mozilla source. Mozilla could just as easily use the font substitutions defined by Windows (as far as I know, it would automatically do that just by calling on the font name in question if it wasn't installed). The portion of the source in question is in gfx/src/windows/nsFontMetricsWin.cpp: http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp#3214 Note that this particular bug applies to not only Seamonkey, but also Firebird and Thunderbird, as well as any other product that uses the Gecko engine!

Yeah, this code looks pretty bogus. dbaron, any reasons _not_ to remove it?

If we don't pick up Windows's substitutions, removing it might break a bunch of web pages.

Moz appears to pick up the Windows font substitutions - defined in the registry key \\HKLM\Software\Microsoft\Windows NT\Current Version\FontSubstitutes on NT systems and %windir%\win.ini on Win9x - from what I can tell experimenting with other substitutions. Seems like this code should be scrapped ASAP.

*** Bug 220657 has been marked as a duplicate of this bug. ***

rbs: MathML code uses this. cc'ing you for input.

I thought about this some more, and some of those substitutions look like they may actually be needed (even the non-MathML ones), depending on what the default Windows substitutions are.

The MathML ones are not important anymore. They can be safely removed now. With that out of the way. { "times", "Times New Roman" }, { "times roman", "Times New Roman" }, I think there is an open problem with these mappings in GfxWin. erik said that it was done wrong (bug 35824 comment 5 - second paragaph), but he only fixed the GTK version (in bug 31013). Also, FirstExistingFont() is not used anymore except by nsFontMetricsPh, and so even bug 35824 comment 5 - his first paragaph may apply. I think all calls were removed from the Style System because it was slow. Hence, this might be the right time to remove the XP aliasing that only FirstExistingFont uses. It is clever, but may be too clever for its own good. As for GfxWin, perhaps, the extra work of the re-mapping is not worth the hassle, and GfxWin can just do what IE does, i.e, nothing. Especially considering that it is done wrong, per erik's comment cited above. =============== { "times new roman", "Times New Roman" }, { "arial", "Arial" }, These are just differences in case, and so they are useless now. (I saw a bug where GfxWin used to be case-sensitive. But it has since been made case-insentive, and so these remnants are not useful anymore.) ================ { "helvetica", "Arial" }, This is the muddy mapping being discussed... ================= { "courier", "Courier New" }, This one has another "issue" that I am aware of... "courier" is bitmap, and "Courier New" is TrueType. This often cause a subtle difference in font-sizes in <pre>, <tt>, etc, which can baffle authors. When they test their pages in IE using "courier", it rounds to a nearest bitmap size. Then, when you look with Mozilla, the text looks smaller or larger (in short: "wrong" to authors). But that's because Mozilla becomes actually more acuratte due to the mapping to the TrueType version. No roundoff arises once the font-subsystem is led to work with the sclalable TrueType version, giving a size much closer to what the author requested, and this may be different from IE shows. But because IE is the dominant browser, they tend to blame Mozilla. I am kind of unsure about whether or not to retain this particular mapping. Explaining such differences to an author is a lost battle, maybe just doing what IE does (i.e., no re-mapping) is good enough. The gain is the removal of some code. ============= { "courier new", "Courier New" }, Another (useless) mapping just to get the case. All in all, removing gFamilyNameTable in GfxWin sounds good to me. It is more critical in GfxWin/Xlib, it is coded properly there, and worth keeping there.

There may be an accessibility issue in this bug. A person with a perception disability (e.g., dyslexia) might use special fonts to compensate. Thus, Comic Sans MS might be used in place of Arial because the letters are more easily distinguished. Having set font substitutions for this in the operating system, it should not be necessary to set them again for a browser. This means that Mozilla should rely on what the operating system says a font is if a substitution is specified. This bug can also be seen in Windows 98. It is not strictly a Windows XP bug.

I almost made a patch to remove it, but I am having some second thoughts prompted by bug 231426. If what is being discussed there doesn't work, we can piggy-back on that gFamilyNameTable to hard-code some mappings: CJK font-name <-> English name. (for some popular CJK fonts). Essentially, this means that the current controversial mappings can be removed, and gFamilyNameTable turned to other uses -- a band-aid solution for bug 231426. Or maybe, use fontEncoding.properties for those CJK name <-> English name mappings. For now, marking a dependency with bug 231426 - and waiting and see what it says.

I still think Helvetica/Arial, Times/TNR and Courier/CourierNew should be removed from the table, even if the substitution table isn't removed entirely...

Poynteronline suggests -- "In Search Of: The Best Online Reading Experience" at <http://www.poynter.org/content/content_view.asp?id=78569> -- the use of three specific fonts for readability: Georgia (serif), Verdana (sans-serif), and Trebuchet (also sans-serif). I set my default serif of Georgia a few years ago, and I just now set my default sans-serif to Trebuchet MS. I chose Trebuchet MS (not having a font named simply Trebuchet) instead of Verdana because with the later a lower-case ell is not easily distinguished from a veritcal bar and (for smaller font-sizes) a two could be confused with an upper-case zee. While my default setting for sans-serif works if no specific font is indicated, a CSS specification in the form of {font-family: Trebuchet, Verdana, sans-serif} will ignore my Trebuchet MS in favor of my Verdana because of this bug. This happens even though I have a Windows font substitution specified in WIN.INI as "Trebuchet=Trebuchet MS". Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060729 SeaMonkey/1.0.4

David E., If you open the font folder in XP you can see the font contained in verdana.ttf is named "Verdana", in comic.ttf "Comic Sans MS", in georgia.ttf "Georgia, pala.ttf "Palatino Linotype", and trebuc.ttf "Trebuchet MS". Thus if you want to guarantee getting the font you wish if it's available, you need to specify it by all possible names across platforms, as follows: font-family: 'comic sans ms', ... ; font-family: 'adobe helvetica', helvetica, ... ; font-family: palatino, 'palatino linotype', ... ; font-family: 'trebuchet ms', trebuchet, ... ;

Source file gfx/src/windows/nsFontMetricsWin.cpp no longer exists. If the issue still exists in current builds, please file a new bug in the gfx:Thebes component