User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030508 Galeon/1.3.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686) Gecko/20030508 Galeon/1.3.6 Mozilla pops up a window that the TeX fonts and the symbol font are missing. The TeX fonts don't need to be there but the symbol font is installed on MacOS X. The rendering is wrong for most symbols, so I think this has to do with the symbol font not found. Reproducible: Always Steps to Reproduce:

The font Symbol is also not displayed for Win 98 running 1.4 and Win XP running 1.5a. Other browsers, and previous versions of Mozilla, display it properly on the same machines. Other fonts seem to display properly. For examples of this behavior see http://www.constitution.org/dh/origcont.htm (last paragraph before the footnotes) http://www.constitution.org/reform/us/tx/redistrict/redist_draft01.htm (paragraph 4(e) where the second p in "p²/4pA" is set to Symbol to display a pi. This bug should be reclassified from MathGL as it is not strictly a MathGL problem, and reclassified as to operating system and platform, since it is not limited to the Mac or OS/X.

I just installed 1.5b on Win XP and found the problem persists.

Further qualification on the original posting. It is not clear how the originator obtained that the browser showed the Symbol and TeX fonts "not installed". When I go into Edit | Preferences | Appearance | Fonts I find Symbol present and available for selection. It just doesn't display strings set to that font in that font. I have not tried TeX, but other fonts I have tried seem to work okay. For some reason the browser seems to be making an exception of "Symbol". Did that become some kind of keyword in recent implementations?

jdr, you have an unrelated "problem". See bug 94319 and references therein.

I have just installed firefox 0.8 on two machines running MacOS X. The problem persists, mathematics fonts are ok, cm fonts are not installed anyway, but the symbol font is still reported as missing, and some symbols are misrendered, in particular some braces and characters like ℕ. The symbol font installed is the standard ttf in Symbol.dfont. However it isn't present either in the Mozilla font selection dialog.

The problem, at least for mozilla 1.7.2 and OSX, is that the method nsDeviceContextMac :: InitFontInfoList takes the font name and converts it, according the font's encoding, to unicode. In the case of the symbol font, the encoding is kTextEncodingMacSymbol and the name "Symbol" gets converted to "Sigma psi mu beta omicron lambda". When math ml goes to look up the font "Symbol", it fails to find it in the list of fonts. If one changes this method to convert the name using the encoding MacRoman instead of MacSymbol, then the name will be converted as "Symbol", and the warning goes away. Unfortunately, math ml starts taking what should be roman letters from the symbol font and thus they appear as greek letters. But torture test 9 has "-" signs where it didn't before. If one changes the font.mathfont-family user pref to specify (in UTF-8) the greek version of the symbol font name, the warning also goes away. The browser appears to behave as it always has, so it's not clear if the font is actually used or not.

Sounds similar to bug 246527 which claims that nsDeviceContextMac :: InitFontInfoList() is broken. > re: comment #4 > However it isn't present either in the Mozilla font selection dialog. This also corroborates that the problem comes from bad APIs. MathML uses nsDeviceContextMac::CheckFontExistence(), which is naturally broken if InitFontInfoList() is broken. I think things will just work in MathML if at least the Symbol font could show up on the Fonts preference dialog. -------- BTW, for those not yet aware, MathML is back and kicking in full force on the Mac now that the dreaded bug 228804 has been fixed.

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

I think Symbol is associated to a special encoding and its name (data) 0x53(S) 0x79(y) ... was converted to "Sigma psi..." there. This patch does special casing for that and as a result Symbol is handled by the ucvlatin converter, so that greek characters are displayed in Symbol. But there remains a bug in which ordinary alphabets get greek.

Since FMGetFontFamilyTextEncoding is broken (bug 95557 comment 12), I googled a bit to get more background information. I stumbled on patch for vim on the Mac: http://www.macvim.org/OSX/files/binaries/OSX10.3/Unicode.diff It includes this snippet of code that might perhaps give a clue on how to get rid of FMGetFontFamilyTextEncoding. This way, it won't be necessary to special-case the Symbol font and it might fix the other bugs that people have seen. --- 1615,1661 ---- * Fill the buffer pointed to by outName with the name and size * of the font currently selected in the Font Panel. */ + #define FONT_STYLE_BUFFER_SIZE 32 static void GetFontPanelSelection(char_u* outName) { Str255 buf; ! ByteCount fontNameLen = 0; ! ATSUFontID fid; ! char_u styleString[FONT_STYLE_BUFFER_SIZE]; if (!outName) return; ! if (FMGetFontFamilyName(gFontPanelInfo.family, buf) == noErr) ! { ! /* Canonicalize localized font names */ ! if (FMGetFontFromFontFamilyInstance(gFontPanelInfo.family, ! gFontPanelInfo.style, &fid, NULL) != noErr) ! return; ! ! /* Request font name with Mac encoding (otherwise we could ! * get an unwanted utf-16 name) */ ! if (ATSUFindFontName(fid, kFontFullName, kFontMacintoshPlatform, ! kFontNoScriptCode, kFontNoLanguageCode, ! 255, outName, &fontNameLen, NULL) != noErr) ! return; ! ! /* Only encode font size, because style (bold, italic, etc) is ! * already part of the font full name */ ! snprintf(styleString, FONT_STYLE_BUFFER_SIZE, ":h%d", ! gFontPanelInfo.size/*, ! ((gFontPanelInfo.style & bold)!=0 ? ":b" : ""), ! ((gFontPanelInfo.style & italic)!=0 ? ":i" : ""), ! ((gFontPanelInfo.style & underline)!=0 ? ":u" : "")*/); ! if ((fontNameLen + STRLEN(styleString)) < 255) ! STRCPY(outName + fontNameLen, styleString); ! } ! else ! { ! *outName = NULL; ! } } ================================== For Gfx:Mac, I wonder if we shouldn't go the same route, i.e., while (FMGetNextFontFamily(&iter, &fontFamily) == noErr) { Str255 fontName; err = ::FMGetFontFamilyName(fontFamily, fontName); if (err != noErr || fontName[0] == 0 || fontName[1] == '.' || fontName[1] == '%') continue; 1/ here... convert it into an ATSUFontID ATSUFontID fid; err = ::FMGetFontFromFontFamilyInstance(fontFamily, 0, &fid, NULL); if (err != noErr) continue; 2/ then... |ATSUFindFontName| as above 3/ then... TECCreateConverter from the Mac encoding to Unicode (as this is font-independent, there will only be _one_ converter now) } // convert font name to UNICODE. ... as before ... =================== On your other point "there remains a bug in which ordinary alphabets get greek". Why is this so? Is Symbol not go through the fontEncoding.properties re-mapping that the other Mathematica fonts get?

> Mac encoding to Unicode (as this is font-independent Roman names for non-western fonts in the UI is not a good user experience. How about using ATS funcs instead of FMs for iteration and name obtaining? 1) ATSFontFamilyIteratorCreate/Next to run thru the fonts 2) ATSFontFamilyGetName to get the name string as a CFString. 3) then get the unicode buffer by CFStringGetCharacters 4) get ATSUFontID by FMGetFontFamilyFromATSFontFamilyRef This means dropping support for Mac OS9s.... as to the ordinary alphabets get greek issue, nsRenderingContextMac::DrawString(const char *aString... is called for simple (u0020 - u007f only?) text blocks. This does not utilize converters as it is supposed to handle 'plain' data. Should we redirect this func to nsRenderingContextMac::DrawString(const PRUnichar *aString.. ?

(In reply to comment #11) > > Mac encoding to Unicode (as this is font-independent > Roman names for non-western fonts in the UI is not a good user experience. I was wondering what encoding is used for oName when |kFontNoPlatform| is passed to |ATSUFindFontName|. According to the vim patch, it's UTF-16, but it's not so likely given that 'oName' is of type 'Ptr' which is just typedef'd 'char *'. So, I suspect it might be UTF-8. If it's indeed UTF-8, we don't need to rely on TEC at all. ATSUI reference doesn't help me with this issue. > How about using ATS funcs instead of FMs for iteration and name obtaining? > 1) ATSFontFamilyIteratorCreate/Next to run thru the fonts > 2) ATSFontFamilyGetName to get the name string as a CFString. > 3) then get the unicode buffer by CFStringGetCharacters > 4) get ATSUFontID by FMGetFontFamilyFromATSFontFamilyRef > This means dropping support for Mac OS9s.... We stopped supporting Mac OS classic a few years ago so that you can just go ahead if you think it works better on Mac OS X.

>as to the ordinary alphabets get greek issue, >nsRenderingContextMac::DrawString(const char *aString... >is called for simple (u0020 - u007f only?) text blocks. This does not utilize >converters as it is supposed to handle 'plain' data. To be precise, this does not affect any MathML text at all, right? This is because MathML set a flag not to use those ASCII functions, precisely to prevent such issues. >Should we redirect this func to >nsRenderingContextMac::DrawString(const PRUnichar *aString.. ? When you have <span style="font-family: Math1"> a </span>, do you also get &alpha; instead? If it is a general problem with Symbolic fonts, then that's best left in another bug. On other platforms, we explicitly lookup & keep an ASCII font meant for |char *| functions only. And since Symbol/Math1/etc get a character map through fontEncoding.properties, their maps don't have 'a' and they are not picked as the ASCII font, and so the mismatch don't arise with them.

#11 errata: step 4) should be "get FMFontFamily by FMGet..." > We stopped supporting Mac OS classic Then nsDeviceContextMac.cpp has a lot of now obsolete codes. HaveFontManager90 and #if TARGET_CARBONs are no longer necessary, aren't they? Cleaning up doesn't look hard, I'm going to try that out. > this does not affect any MathML text ... family: Math1"> a </span>, it looks exactly so. I filed bug 315199.

(In reply to comment #14) > #11 errata: step 4) should be "get FMFontFamily by FMGet..." > > > We stopped supporting Mac OS classic > Then nsDeviceContextMac.cpp has a lot of now obsolete codes. HaveFontManager90 > and #if TARGET_CARBONs are no longer necessary, aren't they? Cleaning up > doesn't look hard, I'm going to try that out. After writing my previous comment, I looked into the file to realize that myself. Please, go ahead and clean that up. Because it's trivial, you may do both (clearning up the obsolete #ifdef'd code and implementing what you proposed) here.

This patch replaces FM functions by ATS counterparts in font enumeration (InitFontInfoList) and drops pre-OS X codes. It turned out really ugly. ATSFontFamilyGetName ignores the font encoding to be useless for non-western fonts. This really sucks Because ATSFontFamilyGetEncoding looks better than FMGetFontFamilyTextEncoding for Symbol handling, there's at least one reason for ATS anyway.. Now we have "Symbol" for it without any special casing.

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes If jshin is happy with this, so will I.

I applied the patch and the result is not satisfactory. Most CJK fonts come up in English names with 'Regular' appended to their names. Moreover, some Korean fonts don't show up at all. I'll do some more testing and tweaking. (there's a possibility that my tree has a couple of old patches mixed in.

Gee... The attachment is the listing of the CJK fonts on my machine."ats qd" is the result of ATSFontFamilyGetQuickDrawName and should appear e.g. in the font list of the pref pane. Are your affected fonts in the list? Or is there one not in the list but available to me?

Hmm.. that's strange (it may be something on my part). Anyway, you can get Korean fonts (Un fonts) that don't show up at all here : http://kldp.net/projects/unfonts/

In my environment Un fonts behaves the same way for Firefox 1.5rc1 and for my own build: Un **** / Un **** Bold in the font list and open squares are rendered for Hangul letters (alphabets, Hiragana and Katakana are okay).

(In reply to comment #21) > In my environment Un fonts behaves the same way for Firefox 1.5rc1 and for my > own build: Un **** / Un **** Bold in the font list and open squares are > rendered for Hangul letters That's a well-known issue. See bug 254585. You may have some handle on that bug, which would be great. (In reply to comment #19) > CJK fonts QuickDraw and PostScript name list (UTF-8) > > Gee... > The attachment is the listing of the CJK fonts on my machine."ats qd" is the > result of ATSFontFamilyGetQuickDrawName and should appear e.g. in the font I distcleane'd and rebuilt firefox. Voila ! It works fine. I don't know what was wrong with my build before. Thanks.

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes r=jshin

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes sr=rbs

Checked-in.

It crashes firefox build process under MacOS-X Tiger 10.4.3 + XCode 2.2, using gcc 4.0.1 Build process is crashing in nsDeviceContextMac.cpp, saying (copying error lines only) : "nsDeviceContextMac.cpp: In member function 'virtual nsresult nsDeviceContextMac::GetSystemFont(nsSystemFontID, nsFont*) const': nsDeviceContextMac.cpp:287: warning: enumeration value 'eSystemFont_Window' not handled in switch nsDeviceContextMac.cpp:287: warning: enumeration value 'eSystemFont_Document' not handled in switch nsDeviceContextMac.cpp:287: warning: enumeration value 'eSystemFont_PullDownMenu' not handled in switch nsDeviceContextMac.cpp: In member function 'void nsDeviceContextMac::FindScreenForSurface(nsIScreen**)': nsDeviceContextMac.cpp:473: warning: unused variable 'rv' nsDeviceContextMac.cpp: In member function 'virtual nsresult nsDeviceContextMac::GetDeviceSurfaceDimensions(PRInt32&, PRInt32&)': nsDeviceContextMac.cpp:517: warning: converting to 'int' from 'float' nsDeviceContextMac.cpp:518: warning: converting to 'int' from 'float' nsDeviceContextMac.cpp: In member function 'virtual nsresult nsDeviceContextMac::GetRect(nsRect&)': nsDeviceContextMac.cpp:553: warning: converting to 'nscoord' from 'float' nsDeviceContextMac.cpp:554: warning: converting to 'nscoord' from 'float' nsDeviceContextMac.cpp: In member function 'virtual nsresult nsDeviceContextMac::GetClientRect(nsRect&)': nsDeviceContextMac.cpp:589: warning: converting to 'nscoord' from 'float' nsDeviceContextMac.cpp:590: warning: converting to 'nscoord' from 'float' nsDeviceContextMac.cpp: In member function 'virtual nsresult nsDeviceContextMac::GetDeviceContextFor(nsIDeviceContextSpec*, nsIDeviceContext*&)': nsDeviceContextMac.cpp:645: warning: converting to 'short int' from 'double' nsDeviceContextMac.cpp:645: warning: converting to 'short int' from 'double' nsDeviceContextMac.cpp:646: warning: converting to 'short int' from 'double' nsDeviceContextMac.cpp:646: warning: converting to 'short int' from 'double' nsDeviceContextMac.cpp: In static member function 'static void nsDeviceContextMac::InitFontInfoList()': nsDeviceContextMac.cpp:803: warning: converting to non-pointer type 'TextEncoding' from NULL nsDeviceContextMac.cpp:827: warning: converting to non-pointer type 'UInt8' from NULL nsDeviceContextMac.cpp:829: error: invalid conversion from 'UInt8*' to 'const char*' nsDeviceContextMac.cpp:829: error: initializing argument 1 of 'nsDependentCString::nsDependentCString(const char*)' make[6]: *** [nsDeviceContextMac.o] Error 1 make[5]: *** [libs] Error 2 make[4]: *** [libs] Error 2 make[3]: *** [libs_tier_9] Error 2 make[2]: *** [tier_9] Error 2 make[1]: *** [alldep] Error 2 make: *** [alldep] Error 2" I am using an one day old homemade firefox build, based on gcc 4.01 to add this comment. So I think this patch is guilty. Am I wrong ? I am using SDK 10.3.9 also.

looks like it's complaining about "invalid" UInt8* -> const char* type conversion. Please make sure that you are not turning on the "char is signed" flag or something else. Explicit typecasting as nsString temp = NS_ConvertUTF8toUTF16(nsDependentCString((const char*)unicodeFontName)); instead of nsString temp = NS_ConvertUTF8toUTF16(nsDependentCString(unicodeFontName)); in the line 829 of nsDeviceContextMac.cpp should work anyway.

Makoto, in C++, char, unsigned char, and signed char are all distinct fundamental types. Earlier compilers would warn about loose usage; GCC 4.0 makes it a hard error. A patch was checked in to correct this problem in bug 316839.

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes In order for me to approve such an involved change to our backend on the 1.8.1 branch, I need to know that there is a big reward in exchange for the risk. I don't think the reward justifies the risk here. Feel free to leave comments if you feel differently, and re-request approval after that.

(In reply to comment #29) Before this patch, you were getting "Symbol font missing" alert dialog once per session even if it's installed when you open a doc containing MathML. This was a major irritation for MathML users on mac along with bug 257978.

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes josh, the patch is actually less scary than it seems. Most of it is cleanup. Only a trivial syntax error not picked up due to different compiler versions was seen and adjusted promptly. It has been baking on the trunk for quite some time.

Comment on attachment 202832 [details] [diff] [review] Use ATS instead of FM in font enumeration and clean obsolete codes (In reply to comment #31) > (From update of attachment 202832 [details] [diff] [review] [edit]) > josh, the patch is actually less scary than it seems. Most of it is cleanup. It looks to me like you're going from FM to ATS, using a completely different API for font ops. That makes me uncomfortable, and since the trunk is and has been in such terrible shape, baking things there recently doesn't mean much. That said, you probably know a lot more than I do about how important this patch is for MathML users since I don't use MathML. If we are going to take this for Firefox 2, we should do it ASAP so we can get as much testing as possile. Please watch this carefully, and we can back it out if anything comes up.

I edited to patch to replace NULL with 0, and Uint8 with char to fix the reported syntax error. But when I applied the patch and updated my tree, nsDeviceContextMac.cpp had a conflict. And this means that I cannot check-in (or change the file to check-in since I don't have a mac build to test such changes). Can somebody else check-in when the 1.8 branch opens? (or provide a patch in sync with the latest 1.8 branch)?

Maybe the conflict came from bug 170854 fix.

The new patch applied cleanly now. The 1.8 branch tinderbox is marked as CLOSED at present. I will wait until it is open before I check in.

Checked in the 1.8 branch.