User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6 In the demo URL <http://web-graphics.com/tests/fontSort.html>, the first and second examples should show Verdana for all systems that do not have Helvetica, and that do have Verdana (which is true on most Windows PCs) - Instead, Mozilla is showing Arial. Mozilla is substituting the Helvetica font-family with Arial, rather than following the font-family specification within CSS files. Mozilla is behaving as if the font Helvetica was accepted, rather than progressing down the priority list to the next available font-family. I also wrote about this on my weblog: http://web- graphics.com/mtarchive/001008.php Reproducible: Always Steps to Reproduce: 1. specify Helvetica in CSS, followed by Verdana 2. do not specify arial, or if you do, specify it after Verdana 3. verify that Helvetica is not installed, and that Verdana is installed Actual Results: The font Arial is shown rather than Verdana Expected Results: Shown Verdana

I suspect the Mac font code intentionally has an alias that maps Arial to Helvetica when Arial is not present, since most macs don't/didn't have it.

This is a Windows bug, not a Mac bug.

According to this reference, Windows automatically aliases Helvetica to Arial and has been doing so for some time. http://lists.w3.org/Archives/Public/www-style/1998Aug/0071.html You say right in your test page that other browsers show the same symptoms as Mozilla, so I don't fathom why you filed this as a Mozilla problem. Suggest that this bug is invalid.

Per comment 3, invalid.

Actually, the discussion in http://web-graphics.com/mtarchive/001008.php doesn't say what comment 3 says, but rather the opposite -- that other browsers behave differently.

The discussion says that, but the test page does not. The test page renders the same for me in Mozilla and Win IE6, WinXP. Arial is clearly being substituted for Helv, presumably by Windows per comment 3. I still think the bug is invalid....

WIN..INI on my W98 system includes: [FontSubstitutes] ... Helvetica=Arial ... This seems to explain why "Helvetica" and "Arial" look identical, regardless whether IE or Mozilla calls either. e.g.: http://qa.mandrakesoft.com/attachment.cgi?id=870&action=view http://qa.mandrakesoft.com/attachment.cgi?id=872&action=view Bug looks invalid to me.

Other browsers have the same bug - namely, they allow the Windows operating system to interfere with the CSS font selection mechanism. Not *all* browsers do this, specifically Opera for Windows does it right. I would think that Mozilla should follow the W3 specs in regards to font selection, even if it means diverting around default Windows mechanisms that interfere. The CSS2 spec seems to have verbiage that supports my take on the situation, such as when <a href="http://www.w3.org/TR/REC-CSS2/fonts.html#font-specification" title="part of the spec about fonts">it states:</a> "These property values form the basis of the user agent's font selection mechanism."

Confirming that the test page does render correctly/without font substitution in Opera 7.2. Given that an implementation exists that defeats the Windows font substitution, I think it's appropriate to resummarize this bug and confirm it as a new RFE for Mozilla. I also note that Windows also defeats the CSS font definitions even if I put then into a user CSS sheet and mark it !important (not that it makes sense to define a Helvetica font that I don't have installed in my user CSS).

I think our current behavior is better, but not strongly. I suspect it's more common for few fonts to be specified than many. Furthermore, nothing requires that the font called "Helvetica" be the same on different operating systems. If Windows wants to have a font called Helvetica that's the same as Arial, that's its problem.

The question is, does the font substitution thing count as meaning that Helvetica is installed? If you query Windows for the list of installed fonts, you don't get Helvetica on the list. It's only if you explicitly try to get a handle to the font despite the font not existing that you get redirected. I suppose it's arguable both ways. Which is better for authors?

I would vote that circumventing the font substitution (like Opera) is better for authors because it is more predictable, and is the expected behavior of the W3 recommendations. The idea of Helvetica being embedded within the Arial font file, yet looking the same as Arial seems like a far cry from actually having Helvetica available on one's machine. I believe fixing this bug would also put Mozilla in the majority of browsers which behave in the way the W3 recommends (cross platforms).

Um... The expected behavior of the recommendation is that if the author lists Helvetica we try to get a Helvetica font. The standard way to use that is to ask the OS for one. Why should we ignore what the OS gives us? How can we even reliably detect that what it gave us is "wrong"? On Linux, should we be making attempts to detect what's listed in font.alias files and second-guess what X is telling us? More to the point, what does "The Helvetica font" _mean_ in any case? This is what dbaron was saying....

I don't know what the technical answers to bz's questions are -- I don't have the background to understand what happens when a browser asks for a font, and what the OS is doing behind the scenes. But from an author standpoint, these are the answers and questions that I see: "Why should we ignore what the OS gives us?" What is the point of an author creating a "prioritized list of font family names" and being "encouraged to offer a generic font family as a last alternative" if the OS is allowed to change the author's priorities with no warning before even getting to the last alternative? 'How can we even reliably detect that what it gave us is "wrong"?' Am I receiving the font family of the name that I specifically asked for? If I'm not, then the answer is wrong. (How would Mozilla know technically that's its getting Arial when it asked for Helvetica -- I have no idea.) 'More to the point, what does "The Helvetica font" _mean_ in any case?' In my view, it means the font named Helvetica on the OS. Not some other font that's being mapped to Helvetica. And regardless if "Helvetica" on this OS looks different from "Helvetica" on another OS. If I want alternatives if Helvetica is not present, I thought the whole idea of font-family CSS is that I define my alternatives right there. As a good encouraged author, I have most likely written sans-serif (for example) as a last resort. If the OS goes through my list of alternatives and doesn't have them and hits sans-serif, *then* it should feel free to do its voodoo and pick a font to use -- not while I still have a list of alternatives available. I'm a reasonably informed author, I think. I know if I'm looking for, say, Times, it might be called Times, or Times New Roman, or some other variation. If it's really of concern to me, I will list out the possible alternatives I know in my CSS in the order I think is most important. The OS should really be trying all those alternatives before arbitrarily picking a font (I think). I don't want it to say "I don't have Times, here's Font X" unless I have coded no alternative selection or the alternatives have been exhausted. Obviously OSes don't do that today. But if there's a way Mozilla can work around that, I think it should. Otherwise, I feel like I might as well just define generic font-families and not worry about anything else, because I have no idea what the OS is doing anyway. Can anyone address why Opera does it? (Not technically how, but what rationale led to the decision to code that ability into it.)

I imagine the way Opera works is that it makes a list of the currently available fonts, then uses that to determine what fonts to use, instead of asking the OS if the font is available each time.

If we assume that's what it does for the sake of argument, wouldn't that also produce better performance by having that 'pre-compiled font list' than having to query the OS each time a font is needed?

Is there a way to tell when the "available font" list that the OS has changes?

Do we currently cache the results of querying for fonts? If so, then it doesn't matter (it wouldn't make us noticably worse). There's a Windows message sent when fonts are updated (WM_FONTCHANGE). I don't know about other platforms though. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_8nxv.asp

This is somewhat related to Bug 145288 which I submitted a while back; perhaps it needs to be reopened... in short, it seems that Mozilla's rendering engine is making this substitution *regardless* of OS settings.

Also, looking at things in a hex editor, this font substitution is apparently *hard-coded* into gkgfxwin.dll in both Seamonkey and Thunderbird, instead of using the font substitutions defined (or not defined) by the OS. This is a Very Bad Thing. (In Firebird, gkgfxwin is compiled into the executable itself rather than being an external library.

And here's *where* it's hard-coded: http://lxr.mozilla.org/seamonkey/source/gfx/src/windows/nsFontMetricsWin.cpp#3214 Just get rid of the substitutions in question and, it seems to me, everything would be fixed.

Why should any but line 3214 be removed?

Why is that line any worse than the others? Marking as dupe of 145288 since it turns out that is what is causing the problems here. *** This bug has been marked as a duplicate of 145288 ***

Because Arial for helvetica is M$'s arbitrary substitution, while e.g. Courier New for courier new and Times New Roman for times new roman are not.

Indeed. And the -moz substitutions need to stay.