In N4.x mail type the following text: test wingdings a b c d: Switch font to Wingdings: <type> abcd ==> NOtice symbol fonts Send and open with trunk latest 4-20-01 Wingding font not visable

invalid - Mozilla is now Unicode-based. There are similar bugs in bugzilla about this 'problem' which you might search for the rationale. Anyway, it is a shame that these glyphs are lost (though some hackery with the user-defined charset might perhaps help to get them).

It is true that we are converting incoming text to Unicode, and that we don't currently support <font face="wingdings">. This use of the font tag is improper, according to the specs and various standards geeks. Of course, if we want to make Mozilla usable on the Net, we may wish to pay some attention to the content that is actually flying around out there. Mozilla's architecture doesn't currently make it easy to support this use of the font tag. One possible solution might be to convert the Unicode text inside the font element back to whatever charset (encoding) was used originally (e.g. iso-8859-1), and then pass that text directly to Windows 'A' functions, e.g. ExtTextOutA. This may require a new concrete subclass of the abstract class nsFontWin. We would also need some way to distinguish between "proper" use of "symbol" fonts (i.e. real Unicodes for glyphs found in "symbol" fonts such as Symbol and math fonts) and "improper" use of the font tag (i.e. things like <font face="wingdings">).

Regardless of the technical issues we can not simply dismiss font compatibility under the guise of standards conformance. If we really want the browser engine to be adopted by countless applications (including windows applications) we must provide as much "common" font compatibility as possible. Reopening the bug and adding Marek for review.

Due to interest from the very important embedding customer I'm setting --- or Future target milestone to 0.9.1

See also bug 33127, "<font face=symbol> not working on Windows"

Reassigning to ftang.

This request is violate the basic principle of the font engine design and CSS. There are no way we can implement this in 3 monthes regardless who request it. Wingding font is neither available on Linux neither MacOS. Sorry, I really can not commit moz0.9.1 for this remove Target Milestone and mark it assign. Can IE do this ?

hum... it's less difficult than I expect- here is the patch.

Index: windows/fontEncoding.properties =================================================================== RCS file: /cvsroot/mozilla/gfx/src/windows/fontEncoding.properties,v retrieving revision 3.1 diff -u -r3.1 fontEncoding.properties --- fontEncoding.properties 2001/05/01 02:35:38 3.1 +++ fontEncoding.properties 2001/05/09 15:56:43 @@ -79,3 +79,5 @@ # MathType Extra encoding.mtextra.ttf = x-mtextra + +encoding.wingdings.ttf = ISO-8859-1

erik did a great job in the window font engine :)

shanjian- can you code review this one?

cc hixie

shanjian give me an r=shanjian on telephone.

change to moz0.9.1

So does this happen just by accident or something? It looks like from what Erik was saying that this should be a lot of work. Does this mean that the wingding encoding is the same as ISO-8859-1? That seems strange to me.

As I understand it, it means we are hardcoding that we want to ignore the font's own encoding information for the particular case of Wingdings -- i.e., we know better than the font for Wingdings, and want to treat it as ISO-8859-1, regardless of what it _actually_ is (probably some obscure symbol encoding that we don't know about). The only other fonts we do this with are Math fonts and the "Symbol" font (which we actually treat correctly, and not in the backwards-compatible fashion, because we have a proper encoding translator written for it). If I'm right, then it's ok, because we are still compliant in every other case, just not for the particular case of the Wingdings font. I think that is probably safe, since the only authors who will attempt to use the Wingdings font are those who are trying to subvert the standards in exactly this way. ftang: Can you confirm that this is what is going on?

yes

OK. sr=blizzard

Warning: it is going to break the handling of the global list (nsIFontEnumerator). If this font comes first there, then all rendering are going to be weird. Some additional logic is needed in the global list so that such hacked fonts are placed last (e.g., using a flag in the property file?).

Theoritically, there is such a problem. If we declare wingdings font contains glyph for latin1 and its cmap will be generated this way. In case we do resort to global font list for certain character and winding font is the first one contains such a character, we would have a problem. However, since global font is the last resort (except subsitute font), and user specified font, font family and default font will be tried first. It is very unlikely that we will ever need to ask any global font for latin1 glyph, I would say it is OK. (Yes, it would be nice to put winding font in the last place in global font list. A better yet way might be to remove all font whose charset is Symbol Character Set. )

If a bad font name (or a font that isn't installed) is specified, say "font-family: uninstalled-font-name" (with a bad generic or without a generic), then all the FindXXXFont will fail, and the code will go straight to FindGlobalFont() where it might pick this wingding font.

I have changed "PRUint8 nsGlobalFont.skip" into a bitfiled, nsGlobalFont.flags, as I commented in bug 69117. Then, when the global list is created, I flag the fonts that are truetype, symbol, ... And later on, I just call quiksort on the list, et voila. (Of note to people starring at the perf clock: this only happens _once_ in the lifetime of Mozilla. And it doesn't happen at startup! except on non-I18N systems where font problems are even more accute. In normal situations, it will usually happen when one visits the Prefs -> Fonts dialog, or in other circumstances of missing fonts as I indicated earlier). There is however one thing curious in the code. The charset information obtained in enumProc is not 100% reliable. Here is a dump from the DEBUG_rbs code on my system: BEFORE SORTING++++++++++++++++++++++++++++++++ 0 TrueType:No Symbol:No System 1 TrueType:No Symbol:No Terminal 2 TrueType:No Symbol:No Fixedsys 3 TrueType:No Symbol:No Roman 4 TrueType:No Symbol:No Script 5 TrueType:No Symbol:No Modern 6 TrueType:No Symbol:No Small Fonts 7 TrueType:No Symbol:No MS Serif 8 TrueType:No Symbol:No Courier 9 TrueType:No Symbol:No MS Sans Serif 10 TrueType:Yes Symbol:Yes Marlett 11 TrueType:Yes Symbol:No Arial 12 TrueType:Yes Symbol:No Courier New 13 TrueType:Yes Symbol:No Lucida Console 14 TrueType:Yes Symbol:No Lucida Sans Unicode 15 TrueType:Yes Symbol:No Times New Roman 16 TrueType:Yes Symbol:Yes Wingdings 17 TrueType:Yes Symbol:Yes Symbol 18 TrueType:Yes Symbol:No Verdana 19 TrueType:Yes Symbol:No Arial Black 20 TrueType:Yes Symbol:No Comic Sans MS 21 TrueType:Yes Symbol:No Impact 22 TrueType:Yes Symbol:No Georgia 23 TrueType:Yes Symbol:No Palatino Linotype 24 TrueType:Yes Symbol:No Tahoma 25 TrueType:Yes Symbol:No Trebuchet MS 26 TrueType:Yes Symbol:Yes Webdings 27 TrueType:Yes Symbol:No Microsoft Sans Seri 28 TrueType:Yes Symbol:No Map Symbols <--------------------------------- 29 TrueType:Yes Symbol:No Arial Narrow 30 TrueType:Yes Symbol:No Book Antiqua 31 TrueType:Yes Symbol:No Bookman Old Style 32 TrueType:Yes Symbol:No Century Gothic 33 TrueType:Yes Symbol:No Garamond 34 TrueType:Yes Symbol:No Haettenschweiler 35 TrueType:Yes Symbol:No Monotype Corsiva 36 TrueType:Yes Symbol:Yes MS Outlook 37 TrueType:Yes Symbol:Yes Wingdings 2 38 TrueType:Yes Symbol:Yes Wingdings 3 39 TrueType:Yes Symbol:Yes MT Extra 40 TrueType:Yes Symbol:Yes Tera Special 41 TrueType:Yes Symbol:No cmex10 42 TrueType:Yes Symbol:No cmmi10 43 TrueType:Yes Symbol:No cmr10 44 TrueType:Yes Symbol:No cmsy10 45 TrueType:Yes Symbol:Yes Math1 46 TrueType:Yes Symbol:Yes Math1Mono 47 TrueType:Yes Symbol:Yes Math2 48 TrueType:Yes Symbol:Yes Math2Mono 49 TrueType:Yes Symbol:Yes Math3 50 TrueType:Yes Symbol:Yes Math3Mono 51 TrueType:Yes Symbol:Yes Math4 52 TrueType:Yes Symbol:Yes Math4Mono 53 TrueType:Yes Symbol:Yes Math5 54 TrueType:Yes Symbol:Yes Math5Mono AFTER SORTING++++++++++++++++++++++++++++++++ 0 TrueType:Yes Symbol:No Trebuchet MS 1 TrueType:Yes Symbol:No Microsoft Sans Seri 2 TrueType:Yes Symbol:No Map Symbols <----------------------------------- 3 TrueType:Yes Symbol:No Arial Narrow 4 TrueType:Yes Symbol:No Book Antiqua 5 TrueType:Yes Symbol:No Monotype Corsiva 6 TrueType:Yes Symbol:No Haettenschweiler 7 TrueType:Yes Symbol:No Garamond 8 TrueType:Yes Symbol:No Century Gothic 9 TrueType:Yes Symbol:No Bookman Old Style 10 TrueType:Yes Symbol:No cmsy10 11 TrueType:Yes Symbol:No Arial 12 TrueType:Yes Symbol:No Courier New 13 TrueType:Yes Symbol:No Lucida Console 14 TrueType:Yes Symbol:No Lucida Sans Unicode 15 TrueType:Yes Symbol:No Times New Roman 16 TrueType:Yes Symbol:No cmr10 17 TrueType:Yes Symbol:No cmmi10 18 TrueType:Yes Symbol:No Verdana 19 TrueType:Yes Symbol:No Arial Black 20 TrueType:Yes Symbol:No Comic Sans MS 21 TrueType:Yes Symbol:No Impact 22 TrueType:Yes Symbol:No Georgia 23 TrueType:Yes Symbol:No Palatino Linotype 24 TrueType:Yes Symbol:No Tahoma 25 TrueType:Yes Symbol:No cmex10 26 TrueType:Yes Symbol:Yes Math5Mono 27 TrueType:Yes Symbol:Yes Marlett 28 TrueType:Yes Symbol:Yes Wingdings 29 TrueType:Yes Symbol:Yes Symbol 30 TrueType:Yes Symbol:Yes Webdings 31 TrueType:Yes Symbol:Yes Tera Special 32 TrueType:Yes Symbol:Yes Math1 33 TrueType:Yes Symbol:Yes Math1Mono 34 TrueType:Yes Symbol:Yes Math2 35 TrueType:Yes Symbol:Yes Math2Mono 36 TrueType:Yes Symbol:Yes Math3 37 TrueType:Yes Symbol:Yes Math3Mono 38 TrueType:Yes Symbol:Yes Math4 39 TrueType:Yes Symbol:Yes Math4Mono 40 TrueType:Yes Symbol:Yes Math5 41 TrueType:Yes Symbol:Yes MS Outlook 42 TrueType:Yes Symbol:Yes Wingdings 2 43 TrueType:Yes Symbol:Yes Wingdings 3 44 TrueType:Yes Symbol:Yes MT Extra 45 TrueType:No Symbol:No System 46 TrueType:No Symbol:No Courier 47 TrueType:No Symbol:No MS Serif 48 TrueType:No Symbol:No Small Fonts 49 TrueType:No Symbol:No Modern 50 TrueType:No Symbol:No Script 51 TrueType:No Symbol:No Roman 52 TrueType:No Symbol:No Fixedsys 53 TrueType:No Symbol:No Terminal 54 TrueType:No Symbol:No MS Sans Serif "Map Symbols" is reported as non-Symbol font... But it _is_ a Symbol font when I look at its glyphs or when I explore it with the Font Properties Extension (http://www.microsoft.com/typography/property/property.htm). Is the charset information in enumProc not reliable?

s/non-I18N systems/I18N systems/

>A better yet way might be to remove all font whose charset is Symbol Character >Set. ) Since there are some legitimate Symbol fonts (e.g., MathML fonts) which are handled without treating them as latin1 fonts, a blanket removal of all Symbol fonts would cause troubles.

Apparently "Map Symbols" is a problematic font. It is said to have bitten IE5.5. http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=79324adc9b963a87,1&se ekm=38F675F48B36D4118E4D00508B5EBA3701492CDA%40cpmsftmsgv21.microsoft.com#p

And there is more... (It is the kind of problems that may arise when fonts like this wingdings font are faked to be treated as latin1 without good safeguards.) http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=b14daf36a4aa0a62,3&se ekm=eUhMKjfzAHA.160%40tkmsftngp03#p

I have verified that "Map Symbols" is going to be kept under control. Why? Because in GetCMAP(), when the font is about to be loaded, another check of the charset is made using this time the GetFontData() function. This function is expensive because it looks up the actual data in the TrueType font file. And so it returns more accurate data. It correctly determines that "Map Symbols" has a SYMBOL_CHARSET, and then GetCMAP() attempts to find its converter. This then fails gracefully and the font is never retained. (Since the GetFontData() function is expensive, it is better to leave things as they are, i.e., not try to use it at the initialization stage to do more work.) Seeking r= and sr= Do people want to add webdings too?

Let's add as few as we can get away with, please... The fonts should use the correct UNICODE code points, and in the absence of appropriate code points, the foundry should submit a proposal to the UNICODE consortium for the new glyphs. Webdings is not as commonly available as Wingdings, anyway. Thanks for the patch!

OK, let's go ahead with the limitation to the strict minimum then. Also, there are strong opinions on this on bug 33127.

one part I think we should change (sorry it's my origional changes) This should be windows-1252 instead of ISO-8859-1 +encoding.wingdings.ttf = windows-1252 rbs- Thanks a lot. After erik resign, you and shanjian probably are the two best person know the Window font handling code.

I like the idea of sorting fonts. This should make it works better and allow space for future extension and improvement. But I have a question about sorting criteria. Truetype font is less important than font's charset, because it only impact the quality of output. That say this part + PRInt32 weight1 = 0, weight2 = 0; + if (!(font1->flags & NS_GLOBALFONT_TRUETYPE)) + weight1 |= 0x2; + if (!(font2->flags & NS_GLOBALFONT_TRUETYPE)) + weight2 |= 0x2; + if ((font1->flags & NS_GLOBALFONT_SYMBOL)) + weight1 |= 0x1; + if ((font2->flags & NS_GLOBALFONT_SYMBOL)) + weight2 |= 0x1; should be changed to + PRInt32 weight1 = 0, weight2 = 0; + if (!(font1->flags & NS_GLOBALFONT_TRUETYPE)) + weight1 |= 0x1; + if (!(font2->flags & NS_GLOBALFONT_TRUETYPE)) + weight2 |= 0x1; + if ((font1->flags & NS_GLOBALFONT_SYMBOL)) + weight1 |= 0x2; + if ((font2->flags & NS_GLOBALFONT_SYMBOL)) + weight2 |= 0x2;

rbs@maths.uq.edu.au- can I reassign to you ?

OK ftang, accepting. shanjian, yes you are right. Unfortunately, non-TrueType fonts don't play nice with mathml. As you might perhaps recollect, they used to be disabled altogether in mathml enabled builds because a growing number of Windows GDI functions are not defined for non-TrueType fonts. An example is the GetGlyphOutline() function which allows to retrieve precise glyph metrics which are then used to do mathml placements. On the other hand, putting TrueType fonts first isn't causing any troubles to this bug (or any other bug to my knowledge). Do you forsee a problem?

rbs, I do understand the requirement for mathml. My question is, will putting all symbols fonts after other fonts cause any problem for mathml? As my understanding of what erik told me before he left, all mathml symbols are assigned to special code point in unicode and will not be found without special encoding conversion. You know better than I do about mathml. So give it a thought and proceeding with your own judgement. Even with your original fix, it should works better that existing code. Just like to make it even better if possible. r=shanjian

Thanks for the r. Because there are many symbols that overlap (e.g., symbols like &alpha, &beta, etc. are very common in fonts these days), I am a bit suspicious that they can be picked from bitmap fonts.

blizzard, can you sr= to finish off this one, thanks.

sr=blizzard

Thanks guys. Checked-in. Resolving as FIXED.

Marking verified per last comments.