213702 - Mozilla says symbol font is missing, although it is installed

Status: RESOLVED FIXED

(Core :: MathML, defect)

Description

[Gérard Milmeister]

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:

Comment 1

[Jon Roland]

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.

Comment 2

[Jon Roland]

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

Comment 3

[Jon Roland]

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?

Comment 4

[rbs]

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

Comment 5

[Gérard Milmeister]

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.

Comment 6

[Andy Fyfe]

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.

Comment 7

[rbs]

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.

Comment 8

[rbs]

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

Comment 9

[YAMASHITA Makoto]

Attachment: Special-cases Symbol in getting the font names

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.

Comment 10

[rbs]

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?

Comment 11

[YAMASHITA Makoto]

> 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.. ?

Comment 12

[Jungshik Shin]

(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. 

Comment 13

[rbs]

>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.

Comment 14

[YAMASHITA Makoto]

#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.

Comment 15

[Jungshik Shin]

(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.

Comment 16

[YAMASHITA Makoto]

Attachment: Use ATS instead of FM in font enumeration and clean obsolete codes

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 17

[rbs]

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.

Comment 18

[Jungshik Shin]

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. 

Comment 19

[YAMASHITA Makoto]

Attachment: 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 list of the pref pane.
Are your affected fonts in the list? Or is there one not in the list but available to me?

Comment 20

[Jungshik Shin]

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/

Comment 21

[YAMASHITA Makoto]

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).

Comment 22

[Jungshik Shin]

(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 23

[Jungshik Shin]

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

r=jshin

Comment 24

[rbs]

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

sr=rbs

Comment 25

[rbs]

Checked-in.

Comment 26

[Frederic Bezies]

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.

Comment 27

[YAMASHITA Makoto]

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.

Comment 28

[Mark Mentovai]

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 29

[Josh Aas]

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.

Comment 30

[YAMASHITA Makoto]

(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 31

[rbs]

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 32

[Josh Aas]

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.

Comment 33

[rbs]

Attachment: attempted synch'ing the patch with the 1.8 branch

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)?

Comment 34

[YAMASHITA Makoto]

Attachment: 1.8 branch patch

Maybe the conflict came from bug 170854 fix.

Comment 35

[rbs]

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.

Comment 36

[rbs]

Checked in the 1.8 branch.