Mozilla 1999121508 on WinNT does not recognize 'MS Sans Serif', either as <FONT FACE='MS Sans Serif'></FONT> or as "font-family: 'MS Sans Serif'". Navigator 4.7 on the same machine does display properly using this font. Couldn't find a DUPL. Guessing 'Style System'. Attaching minimum test case. Properties for \winnt\fonts\sserife.fon are Version: 4.10.1684, ``MS Sans Serif font 8,10,12,14,18,24 (VGA)''

It seems to only happen with that particular font. If you change "MS Sans Serif" to "Impact" or "Courier New Italic", it works. It's probably a problem in nsDeviceContextWin.cpp for which there is no clear owner. Reassigned to dcone who certainly can help.

I noticed also that Verdana wasn't working. And then I tried the most common fonts used in web pages -- the _most_ common display: Courier, Courier New, Times New Roman, Arial, Helvetica (plus Impact which is less common). But Tahoma, Verdana, and Georgia don't display in addition to 'MS Sans Serif'. I didn't test every font [partially since I don't know what some of them are supposed to look like anyways ;)]

Doh. I don't have Helvetica, but I got a sans-serif font, but I assume this is an intentional kludge.

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

Georgia, Tahoma and Verdana work for me on NT4. MS Sans Serif does not work because it is not a TrueType font. This is a limitation of the current Windows GFX code that I wrote.

Moving all M16s to M17. Please make comments if you disagree.

Not limited to NT; also fails to use requested MS Sans Serif on Win98. Many sites are using this font since it is compact and legible at smaller sizes; cf http://www.cnet.com/

Erik -- here's the min. test case I've been using for this bug: <title>bug24003</title> <span style="background-color:yellow"><a href="bug24003.html">Next...</a></span><br><br> <TABLE BORDER=1> <TR> <TD> <FONT FACE="geneva, ms sans serif"> <A HREF="foo">text here</a> </FONT> </TD> </tr> </TABLE>

My guess is raster fonts (versus TrueType fonts) don't work (yet). Another issue is when both types of fonts are present with the same name. My pet problem is the "Symbol" font which is normally installed on Windows PCs as both a raster font and a TrueType font. It appears that Windows is "mapping" the raster not the vector font and...the raster font is not yet supported in Mozilla. I really need the symbol font for my website which displays calculus problems and at this point I can only tell users "don't use Netscape 5, try 4.x or (shudder) Internet Explorer." At the least, how about a look into getting the font mapper to load the TrueType font when it is available rather than letting Winders pick it for you.

Roger, please take a look at the previous comment in this bug report. It talks about the bitmap and TrueType versions of Symbol. I believe you dealt with that at one point. Did you actually check anything in for that? Thanks!

Yes, erik, I checked a change to give precedence to TT fonts. The selection involves LOGFONT.lfOutPrecision. To alter the font mapping algorithm, the values of lfOutPrecision that are of interest are: OUT_TT_PRECIS Instructs the font mapper to choose a TrueType font when the system contains multiple fonts with the same name. OUT_TT_ONLY_PRECIS Instructs the font mapper to choose from only TrueType fonts. If there are no TrueType fonts installed in the system, the font mapper returns to default behavior. I was having the very same problem described above, and I changed the font code in nsFontMetricsWin::FillLogFont() to use OUT_TT_PRECIS; this fixed the problem. As a matter of fact, the documentation says "if an operating system contains a font named Symbol in raster and TrueType form, specifying OUT_TT_PRECIS forces the font mapper to choose the TrueType version. Specifying OUT_TT_ONLY_PRECIS forces the font mapper to choose a TrueType font, even if it must substitute a TrueType font of another name." It is rather curious that MarkCarson@hawaii.rr.com is still having the problem. We can still try OUT_TT_ONLY_PRECIS which "specifies that only TrueType fonts should be considered for the exact matching. None of the other types of physical fonts are considered. This filter is useful for an application that wants to guarantee that the realized font is a TrueType font."

Erik and Roger, thanks for looking into this bug. I see the "logFont- >lfOutPrecision = OUT_TT_PRECIS;" statement on line 191 of the checked in code. Just a thought here, but is the Symbol font considered to be a different character set versus just a font face? If so the previous line (190) which reads "logFont->lfCharSet = DEFAULT_CHARSET;" may the problem. Your thoughts?

FillLogFont() is primarily used to enumerate available TT fonts. There is another place where the SYMBOL_CHARSET is detected an used to override the default charset (when actually loading the font, see lines 1045-1058, and lines 1493-1497.) BTW, on which platform/version are you seeing the problem.

My problem with the Symbol font is on Windows NT 4.0 (both server and workstation). I have seen this problem for many months (M12, M13, M14) and it continues through the nightly build of 16-MAR-2000. The system is usually run the nightly build against has the raster font "Symbol" (symbole.fon), the TrueType font "Symbol" (symbol.ttf), and a TrueType font which I believe is called "Symbol Proportional".

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

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

Erik, may I suggest raising the priority on that bug? I put M15 after checking your bug list.

Pierre, I'd like to understand why you'd like to raise the priority. Is it because CNET use MS Sans Serif? I know what I need to do to resolve this bug. Currently, the font engine relies on TrueType "cmap" tables to figure out which glyphs are present. Since bitmap fonts don't have cmap tables, it's hard to tell (programmatically) which glyphs are there. A quick look using charmap on Win95 shows that most of the Windows extensions of ISO-8859-1 (i.e. 0x80 - 0x9F) are missing in MS Sans Serif. This includes the euro, trademark, ellipsis, mdash, some smart quotes, etc. However, all of the ISO-8859-1 glyphs are there. So I suppose I could look at the results returned by Windows's font enumerator to see which Windows charset is supported by bitmap fonts, and then assume that even if it says ANSI_CHARSET, that it isn't really complete, and only contains ISO-8859-1. Then the font switching machinery can continue its search, moving on to fonts that *do* contain those glyphs. We would probably end up with TrueType fonts for those glyphs. Oh well, there isn't much else that we can do about deficient fonts now, is there? I assert that this is merely a *bug*, as opposed to a *feature*, and since I am still in the feature implementation mode as we head towards the M16 feature completion date, I am setting the target to M17. If anybody wants to have this fixed sooner than that, they can fix it themselves, based on the info I have provided above.

Yep, I rose the priority because of CNet. ICQ has the same problem (maybe even worse - I wrote the webmaster about it). You graciously lent your time on font issues during quite some time and it's been very much appreciated but, of course, if you no longer have the oppportunity to work on it, please reassign to the usual suspects: dcone or kmcclusk.

I'm going to close bug 33127 as dup of this one. It has a nice testcase at the following url: http://www.mozilla.org/quality/browser/bft/bft_image_trans.html Interestingly enough, this page is one of the very first demo pages used in Gecko. It doesn't work anymore because it uses Symbol.

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

I marked bug 33127 INVALID, because if the document asks for the text "Opaque", the browser is supposed to render that with glyphs that resemble that English word, rather than some Greek gibberish from the Symbol font. Bug 33127 is not related to this bug.

Bug 31538 shows that the problem occurs even with fonts that exist only as TrueType fonts, which means that your explanation from 2000-01-17 19:41 isn't valid. We should raise the priority on this problem.

The current font selection code relies on Unicode points. There is no (yet) a rendering based on direct glyph indices. This may explain why the <FONT FACE=""> are not working as in old versions of Nav. For example, if the document contains <font face="symbol">a</font>, then GFX will render "a" instead of the glyph whose index is the numeric value "a". MarkCarson@hawaii.rr.com, do you see something when you try this little document: <head><title>Symbol</title></head> <body> alpha: &#x03B1; beta: &#x03B2; </body>

Reply to question from rbs@maths.uq.edu.au dated 2000-03-25 01:01: Your test HTML document (which used Unicode values for Symbol glyphs) DOES work correctly in Mozilla nightly build 2000032308. Also Internet Explorer 5 displays this unicode correctly. Unfortunately, Navigator 4.7 does NOT. <RANT> I appreciate that unicode is a better way to express the symbol and a move forward for browsers, however.....because Navigator 4.x still does not support this encoding, I once again have to create 2 versions of web pages which need the Symbol font, or I write conditional code into ASP and JSP (which also makes every one of these pages dynamic versus static pages with associated performance penalty). I surely support the level of compliance aimed for via unicode, but backward compatability is essential to not break existing pages which "work" with previous versions of Navigator. I could see it if the position was to not be compatible with older versions of IE, but to orphan existing Navigator pages will alienate content creators who are currently loyal to Netscape and look forward to a smooth migration to Mozilla. Ponder for a moment the slow acceptance of Windows 2000 server because of its lack of backward compatiblity and interoperability with Windows NT 4 and 9x. Does the Mozilla effort really want to get aboard that kind of sinking ship? I hope not. </RANT> Also I have to cop to a bug in my example HTML code. The "default example" row also has SYMBOL specified and it should not, so it displays whatever face as the following row which is the "SYMBOL example" row. My humble apologies. Pierre, can you correct the code by removing the "FACE" attribute in the FONT tag on the offending row? -- Mark Carson 0205/25-MAR-2000

So GFX is behaving as expected (i.e., by design). And the problem reduces down to yet another difference when the NavQuirk mode is enabled. Under this mode, GFX should interpret chars as glyph indices. This is something that Erik, and Pierre can now decide what to do about. If this is done, many of the <font face> "bugs" could go away. (The fact that bitmap fonts are not yet supported is a separate issue.)

I'd agree with that and commented about it in bug 33258.

Bug 6585 has also other options (in addition to this NavQuirks mode) to make the rendering less monolithic. BTW, the char* functions that are in nsRenderingContextWin.cpp seem to be the functions that were in use at the time of the demo. These functions are still there but are not called anymore from layout.

Nominating for nsbeta2 because we will be using CSS system fonts in HTML buttons (in html.css) and Windows sets the default system fonts to MS Sans Serif, which is a bitmap font that does not work in Mozilla yet. As Pierre mentioned in this bug report, MS Sans Serif is also used on CNet and ICQ.

Native-looking skins also depend on this capability. It would be a greatly appreciated fix.

[nsbeta2+]

Adding '4xp' and 'fonts' keywords.

who need to review the code ?

I reviewed it, it looks good and works

Erik, classic skin is ready to use this whenever you check in the fix.

Checked in the fix.

John, This appears to be fixed in the July 17th build under Win 98. Could you please verify bug in the latest build too.

Verified as fixed in 2000-07-19-10 Win32 build.

Does not work in Build 2000072408 Windows NT 4.0 Workstation Installed fonts: TT "Symbol", Raster "Symbol 8,10,12,14...", TT "Symbol Proportional"

What do you see that is not working? What was your expectation?

I cannot see anything wrong with the current version. We do use "MS San Serif" font from the 1st test cases if it installed in the system. We do not use the glyph from Symbol to rendert ASCII or other non Symbol characters, but that is the right thing. Mark this bug FIXED again.

Mark Carson: for more info about the Symbol font, see bug 33258 and bug 31538.

Marking fixed in the July 26th build.