Closed Bug 128153 Opened 23 years ago Closed 21 years ago

need to get MathML fonts working with Xft

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: blizzard, Assigned: blizzard)

References

Details

Attachments

(14 files, 6 obsolete files)

screenshot with '+' sign
25.00 KB, image/jpeg
Details
screenshot with '-' sign
35.08 KB, image/jpeg
Details
another shot with bm correct
27.90 KB, image/jpeg
Details
screenshot taken with unpatched Mozilla (1.3)
44.01 KB, image/jpeg
Details
screenshot with 'correct' bm
38.24 KB, image/png
Details
another screenshot with pure html case included
30.54 KB, image/png
Details
screenshot with CSS metric right
37.75 KB, image/png
Details
math ml toture page rendering result
61.69 KB, image/png
Details
MathML in Action page
122.02 KB, image/png
Details
the log of a Mozilla-run testing the above case
9.42 KB, text/plain
Details
a really simple case with which attachment 122730 was obtained
1.40 KB, text/xml
Details
stretchy.xml with black holes
69.71 KB, image/png
Details
start.xml example with very small subscript characters
52.70 KB, image/png
Details
magnified stretchy square root from start.xml
5.01 KB, image/png
Details 
Need to get the MathML fonts working with Xft.  Bug #35236 has some good hints.
Blocks: xft
Blocks: xft_tracking
Make it depend on bug 176290. 

A question to rbs. In fontEncoding.properties file for MS-Windows and MacOS, 
there are entries like 'Math1-Bold'. Do Windows and MacOS return
family names with '-Bold' appended at the end when requested for
fonts with 'bold' weight/style? Otherwise, it seems to me
that those entries are not necessary. MSDN document on 'EnumFontFamilyEx'
is not clear, but it seems not because Mozilla's font selection menu
(under Windows) doesn't list any font with '-Bold' at the end. Of course, 
it could well be that Mozilla filers them out. (perhaps, I've gotta
experiment instead of asking...)

 Anyway, the relevance of this issue to
Mozilla-Xft and MathML is that if MathML layout engine in any way
needs  fonts with 'bold' style to have '-Bold' at the end of
their family/face names or have to(though very unlikely) request fonts 
like 'Math1-Bold' 'directly' (as opposed to asking for 'Math1' with
'Bold' style), I think  the font configuration file (fonts.conf)
has to have a set of editing rules to meet that need. I made it last night,
but I'm wondering if MathML layout engine needs it.
Depends on: 176290
*** Bug 179922 has been marked as a duplicate of this bug. ***
*** Bug 183608 has been marked as a duplicate of this bug. ***
Is there some progress on this issue. MathML is important for
our project, so it would be nice to hear about it.
Once bug 176290 is fixed, it's pretty easy to fix this one(basically,
writing up BoundingMetrics... would do it). 
There's been a working patch for bug 176290 for a while, but something else
is being worked out so that you need to wait a bit longer.
Now that a patch that has gone in for 176290 (although it isnt marked as fixed)
is it likely that this bug will be fixed so that MathML fonts will work with Xft
in 1.4? 

I'm looking at using DocBook slides for presentations/lectures with MathML and
SVG content and dropping back to non-antialiased fonts (in which MathML still
renders properly) now feels such a backwards step.
Sorry the answer is no. The patch checked in for bug 176290 (attachment 117081 [details] [diff] [review])
did not fix bug 176290 per se. It just paved a way for a less complicated
and less fragile solution than my  patch for bug 176290(attachment 116195 [details] [diff] [review]) that 
did not get in. 
jshin, did you want to work on that or were you expecting me to hack on it?  I
think we might have gotten off track a bit.
Chris,
I was under the impression that you would work on that and have been waiting. 
If you're too busy or otherwise you can't for a while, I'm willing to work on it.

BTW, my answer in the prev. comment was not meant to say it's unlikely that
1.4 would have MathML. (I think it's likely) Somehow I thought Geoff's question
was whether MathML works in CVS snapshot. Otherwise, I would not have made that
definite statement.

Woops, sorry.  I was waiting on you. :)  OK, I'll put some time aside to work on it.
Sounds great. I'm sorry, too. I should have asked once more, but I didn't want to 
bug you too often :-) For any reason, if you get sidetracked (by other
bugs/issues), let me know and I am more than willing/love to work on bug 176290 
as well as this one.
OK.  I'll let you know when I get started.  I need to work on the text input
problems with gtk2 first and once that's solved, I'll come back to this.
Thanks for refocusing on this ... 

IMHO native MathML (together with SVG) support will help make Mozilla the
browser of choice for the scientific and technical community - if it isnt already.
*** Bug 196460 has been marked as a duplicate of this bug. ***
*** Bug 200352 has been marked as a duplicate of this bug. ***
New roadmap has 1.4 as (probably) the last all-in-one Mozilla, and also the base
for the next Netscape release. 

Could I politely request if possible that this bug gets fixed for 1.4 ...

Chris, would you mind if I work on this and bug 176290?
As  Geoff and others do, I'd love to see this and bug 176290 fixed
before 1.4. 
Sure, go right ahead.  I haven't had the time yet.
Attached image a screenshot with my patch to bug 176290 (obsolete) — 
Thanks, Chris. I uploaded a patch to bug 176290 as you noticed.

Not yet working correctly, but appears promising..
Attachment #120406 - Attachment is patch: false
Attachment #120406 - Attachment mime type: text/plain → image/jpg
Attached image better looking result (obsolete) — 
better than before(with a sign change in GetBoundingMetrics), but still 
something is wrong...
Attachment #120406 - Attachment is obsolete: true
You might want to take a look at bug 124543.

A good way to test your implementation is to enable #define SHOW_BOUNDING_BOX 1:
http://lxr.mozilla.org/seamonkey/source/layout/mathml/base/src/nsIMathMLFrame.h

Then, maybe after a number of iterations (like in the screenshots in bug
124543), you will sort things out.
Roger, thank you for the comment. I'll try that.
Am I right to assume that nsFontMetricsXft::GetBoundingMetrics()
is the only thing I need to get right?   

In the meantime, I found out why 'ordinary' fonts instead of
slanted/italic (as usually found in math expressions/formulae)
were used in attachment 12040 [details].
I turned on PR_LOG for XftFontLoad and the following shows the cause.

--------------------
setting up pattern with the following specification:
        adding non-generic families: cmsy10, symbol, times, lucida sans unicode,
mt extra, math1, math2, math3, math4, math5,
        lang group: ko
        adding generic font from preferences: UnBatang
        adding generic family: serif
        point,pixel size: 9,170
        slant: italic
        weight: (orig,calc) 400,100
matched the following (17) fonts:
        cmsy10 Symbol Math1 Math5 UnBatang
        Baekmuk Batang New Gulim Arial Unicode MS
        Gulim Nimbus Roman No9 L ZYSong18030
        AR PL Mingti2L Big5 Nimbus Mono L
        Gothic TITUS Cyberbit Basic
        Code2000 Standard Symbols L
------------------------

  The font matching by fontconfig(used by Xft)
is strongly influenced by langgroup. With that set to ko,  MathML engine's
preferences 
(cmsy10, symbol, times, lucida sans unicode, mt extra, math1, math2, math3,
math4, math5) don't get respected much. The font selected for Latin letters
and numbers is 'Unbatang' (the first one in the list above 
with the full US-ASCII coverage in the match), but that one comes only
in 'roman' (no 'italic'). 

  With the locale set to C or en_US, this problem gets solved. Now I'm
wondering if MathML engine can set  langgroup to something 'neutral'
such as 'x-western'(overriding the one determined from the locale
but NOT the one specified by the document authors with html lang
or xml:lang) when 'entering <math...>'.  That way,
non-Western-European-language-speaking users don't have to change their locales
to render MathML.
  
Alternatively, fonts like 'cmmi' and 
'cmr' could well be explicitly specified early in the requested
font list for Latin letters and numbers. The XftFontLoad log
file doesn't have any trace of cmmi/cmr ever requested. If that's not
always desirable, either the meaning of 'user_pref("font.mathfont-family"'
could be extended for non-strechy letters/glyphs/chars or a new pref.
is added for mathml text font preference.

I'm afraid this is kinda off-topic here and perhaps I'd better file a new bug
on this issue.
Target Milestone: --- → mozilla1.4beta
The gut of my code is as following:


nsresult
nsFontXft::GetBoundingMetrics32(const FcChar32*    aString,
                                PRUint32           aLength,
                                nsBoundingMetrics& aBoundingMetrics)
{
    aBoundingMetrics.Clear ();
                                                                               
      
    if (aString && aLength) {
        XGlyphInfo glyphInfo;
        GetTextExtents32 (aString, aLength, glyphInfo);
        aBoundingMetrics.leftBearing = glyphInfo.x;
        aBoundingMetrics.rightBearing = glyphInfo.width - glyphInfo.x;
        aBoundingMetrics.ascent = -glyphInfo.y;
        aBoundingMetrics.descent = glyphInfo.height + glyphInfo.y;  // *****

        aBoundingMetrics.width = glyphInfo.xOff;
    }
    return NS.....
}

Now I'm gonna upload two screenshots. One was obtained with
the above while the other was obtained with the line
commented with '// *****' replaced with the following:

      aBoundingMetrics.descent = glyphInfo.height - glyphInfo.y;

It seems like it's time to 'torture' my hard disk ... :-)

    
    

    
  


  
'+' sign seems to be correct (if the rendering origin below
is the baseline and descent is positive when it's below the
baseline), but it's worse than '-' sign (which should be
right according to Xft doc quoted below). Neither of this leads to
the correct rendering. 
Well, there are 8 combinations (assuming I understand MathML
convention correctly). If I can't figure out, I'll try the rest 6.... 


------------- 
The metrics for each glyph are described by an XGlyphInfo structure:
									       
      
	typedef struct _XGlyphInfo {
	    unsigned short  width;
	    unsigned short  height;
	    short	    x;
	    short	    y;
	    short	    xOff;
	    short	    yOff;
	} XGlyphInfo;
									       
      
Width/height are the size of the glyph image in pixels.  x,y is the offset
from the origin of the glyph image to the rendering origin.  xOff, yOff is
the normal spacing to the next glyph.  Note that x,y is backwards, the
location of the bitmap is computed by subtracting them from the rendering
origin.  So, to compute the rectangle covered by a single glyph rendered at
x,y:
									       
      
	top = y - glyphInfo.y;
	left = x - glyphInfo.x;
	bottom = top + glyphInfo.height;
	right = left + glyphInfo.width;
									       
      
And to compute the normal location for the next glyph:
									       
      
	x = x + glyphInfo.xOff;
	y = y + glyphInfo.yOff;
									       
      
The "width" of a glyph is thus found in the xOff member of this structure.

    
    

    
  


  
gdb is a good friend :-). Now I got ascent/descent right, but
the interaction with the rest is still strange. In the screenshot,
all bm boxes(blue) are drawn correctly, but red dotted lines are still
widly off for mathml and mathml + html cases while they're right on
for html alone. Mozilla 1.3 behaves exactly the same way
(except that MathML font-encoding doesn't work for the obvious reason) 

-----------------
	XGlyphInfo glyphInfo;
	GetTextExtents32 (aString, aLength, glyphInfo);
	aBoundingMetrics.leftBearing = glyphInfo.x;
	aBoundingMetrics.rightBearing = glyphInfo.width - glyphInfo.x;
	aBoundingMetrics.ascent = glyphInfo.y;
	aBoundingMetrics.descent = glyphInfo.height - glyphInfo.y;
	aBoundingMetrics.width = glyphInfo.xOff;
-------------

BTW, I also noticed the problem with left-bearing and I'll take care of it.

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot taken with unpatched Mozilla (obsolete)
        — 
      

    


  
This is to show that there's disagreement between MathML rendering engine's
notion of 'lineheight' and nsFontMetricsXft's notion. In contrast
to the result in the screenshot, the following lines
get rendered fine with red-dotted box spanning from font's
descent to font's ascent. 

HTML:
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot><br />
HTML: 
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot>

It looks like somewhere someone is adding extra 'ascent' to 'descent' 
(i.e. descent is set to descent + ascent). I couldn't find anything
obviously wrong in nsFontMetricsXft, though.

Roger, can you tell me which method of nsIFontMetrics is used
to determine 'line spacing' by layout(e.g. when drawing
border box) ? (There are several methods
that may be used and all look fine to me in Xft.)

    
    

    
  


  
This is to show that there's disagreement between MathML rendering engine's
notion of 'lineheight' and nsFontMetricsXft's notion. In contrast
to the result in the screenshot, the following lines
get rendered fine with red-dotted box spanning *only* from the font's
descent to the font's ascent. 

HTML:
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot><br />
HTML: 
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot>

It looks like somewhere someone is adding extra 'ascent' to 'descent' 
(i.e. descent is set to descent + ascent). I couldn't find anything
obviously wrong in nsFontMetricsXft, though.

Roger, can you tell me which method of nsIFontMetrics is used
to determine 'line spacing' by layout(e.g. when drawing
border box) ? (There are several methods
that may be used and all look fine to me in Xft.)

    
    

    
  


  
This is to show that there's disagreement between MathML rendering engine's
notion of 'lineheight' and nsFontMetricsXft's notion. In contrast
to the result in the screenshot, the following lines
get rendered fine with red-dotted box spanning *only* from the font's
descent to the font's ascent. 

HTML:
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot><br />
HTML: 
<span><i>jif</i><sup><i>jif</i></sup></span><dot>.</dot>

It looks like somewhere someone is adding extra 'ascent' to 'descent' 
(i.e. descent is set to descent + ascent). I couldn't find anything
obviously wrong in nsFontMetricsXft, though.

Roger, can you tell me which method of nsIFontMetrics is used
to determine 'line spacing' by layout(e.g. when drawing
border box) ? (There are several methods
that may be used and all look fine to me in Xft.)

    
    

    
  
Let's concentrate on the bounding metrics before taking a tangent in the
wilderness of line-height.

The reference shot for the jif testcase is attached to bug 124543 comment 16:
screenshot: http://bugzilla.mozilla.org/attachment.cgi?id=72919&action=view

The testcase contrasts the bounding metrics vs. the usual CSS metrics. The solid
blue borders are done with the bounding metrics while the dashed red borders
are done with the CSS metrics. The dashed red borders may be way off, but the
blue ones should surround the glyphs (except in those cases of MathML+HTML where
the inner bulky HTML doesn't know the notion of bounding metrics and is
returning its CSS metrics which get used as the fallback "bounding metrics").

Anyway, to cut the story short, what you must get similar with the reference
shot in attachment 72919 [details] are the blue borders. In your "another shot with bm
correct", I notice that there is still a little excess in the right bearing of 'i':
screenshot: http://bugzilla.mozilla.org/attachment.cgi?id=120428&action=view

    
    

    
  
Also, the left-bearing is still incorrect. The 'j' shouldn't protrude outside
the blue borders in the pure MathML cases.

    
    

    
  


  
Now I guess I got the bluebox right. In the following,
I meant to set firstTime to 'PR_TRUE', but somehow I used 'PR_FALSE', 
instead. As can be seen in the shot, the left bearing of 'j' and 'f'
are now correct.

    // the beginning of a string needs a special treatment (see
    // 'operator +' definition of nsBoundingMetrics.)
    data.firstTime = PR_TRUE;

As for the right bearing of 'i' in attachment 120428 [details] (which was
taken with Mozilla running under ko locale and which uses a different
font from the one used in this shot), I think the font has the incorrect
metric( 'ink width') Both 'i' and 'f' have positive left bearing 
(rightward from the origin), but the RB of 'f' is correct while that of 
'i' is off even though 'RB' is obtained the same way for both glyphs. 
It is calculated by  adding the 'ink width' (blackBox width) of glyph 
to 'left bearing'. The ratio of the actual inkwidth of 'j' to that of 'i'
(I measured on the screen) is about 7:5 while the corresponding
number obtained from the fontmetric is 8:7 via Xft. In addition to that,
'j' and 'f' glyphs of the font in attachment 120428 [details] appear to have 
'ink width' slightly larger than the actual ink width, which accounts
for a small gap on the right (or it may be due to round-off error?).
I'll track down the font to check the metric stored in the font.

P.S.
I'm very sorry for spamming with three identical messages (I was 
timed out by bugzilla and when I was the other day, it's not processed, 
but this time the timing must have been different)

        Attachment #120443 -
        Attachment is obsolete: true

        Attachment #120444 -
        Attachment is obsolete: true

    
    

    
  
> As for the right bearing of 'i' in attachment 120428 [details] (which was
> taken with Mozilla running under ko locale and which uses a different
> font from the one used in this shot), I think the font has the incorrect
> metric( 'ink width')

  I checked the font (UnBatang.ttf) and turned out that it's not an oblique
font, but I have font.config setting for the on-the-fly generation of artificial
'oblique' fonts. It seems like some metrics got screwed in the matrix 
transformation for artificial 'obique'. Anyway, it's not a Mozilla issue.

Now the remaining question is why CSS metric boxes (red dotted box) are so 
much off.
Even without fixing it, MathML sorta works, but it's elongated a lot
in the vertical direction


    
    

    
  


  
To give a little more info. as to what's going on....

    
    

    
  


  
Finally, I tracked down the cause of the incorrect CSS metric.
Roger and I talked about a potential problem with mWesternFont
not being a genuine western font several months ago. That's what
happened and one of MathML fonts with the custom encoding was
used to get the overall metrics (XHeight, EmHeight, etc) because
I forgot to replace |FcCharsetHasChar| with |HasChar| in one
place (|FindFont|) in my patch to bug 176290. (I may have
to make it more robust because having 'a' is not a sufficient
condition for NOT being a MathML font with unusually long 
stretch glyphs).

    
    

    
  


  
just to show how it get rendered. btw, it's taken under ko locale and 
the font for Latin letters doesn't look good.

        Attachment #120408 -
        Attachment is obsolete: true

    
    

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

    
    

    
  
I've seen the MathML torture test screen shot in jshin's attachment
http://bugzilla.mozilla.org/attachment.cgi?id=120562&action=view
I want it to work for me :-)

Preliminaries:

i) RH8 (up2date, with some relevant packages manually
upgraded from rpmfind), Xft-2.0-1, fontconfig-2.1-9, XFree86-4.2.0-72.

ii) When I sidestep using Xft MathML renders fine - except for the
retro aliased look. Actually, make that the now pretty much
unacceptable aliased look :-)

I've applied the patch from 176290 to my tree and rebuilt.

Issues:

1) Xft and AMS fonts

I've run fc-cache on my Tex CM fonts (downloaded from the link on
http://www.mozilla.org/projects/mathml/fonts/)
I get the same behaviour as reported in
http://mail.fontconfig.org/pipermail/fontconfig/2003-February/000083.html.
fc-list reports all fonts as "Computer Modern" family. None are
reported as CMEX10 or CMSY10.  The Mozilla MathML font warning/nagger
tells me I need to install CMEX10 and CMSY10.

It seems Xft is not reporting the AMS fonts to Mozilla in the way
Mozilla wants them. To confirm, I hand-edited font.cache-1 and changed
the font family entry for file/font cmex10.pfb from "Computer Modern"
to "CMEX10", and likewise for the CMSY10 font. Then fc-list reports
CMEX10 and CMSY10 family and Mozilla no long nags me about those
particular fonts. But it didnt help with the torture test.

2) Symbol font

I'm finding fc-cache will not cache the X11 symbol fonts in
/usr/X11R6/lib/X11/fonts/75dpi
/usr/X11R6/lib/X11/fonts/100dpi
which are part of
XFree86-75dpi-fonts-4.2.0-72 and
XFree86-100dpi-fonts-4.2.0-72.
Upgrading the fonts to XFree86-100dpi-fonts-4.3.0-8 and using
fontconfig 2.2 didnt change.

I used
FC_DEBUG=384 fc-cache -f -v .
to see more detail - the symbol fonts are processed but do not result in a
cached font.


In the fontconfig maillist
http://mail.fontconfig.org/pipermail/fontconfig/2003-April/000253.html
it is mentioned that
"Fontconfig (and Xft) are only interested in fonts with a Unicode encoding,
fontconfig explicitly skips .pcf fonts which are encoded in some other way."
Is that the reason?

I looked (google) for a unicode encoded symbol font. Where do I them?

3) Mathematica fonts

Mathematica has revd (sp?) from 4.1 to 4.2. The 4.1 Mathematica type1 fonts 
work as described in the MathML documentation, providing families
"Math[1-5]." The 4.2 Mathematica fonts now have family names of
Mathematica[1-5]. Something to watch for.

4) user_pref("font.mathfont-family", "Math1, Math2, Math4");

I set user_pref("font.mathfont-family", "Math1, Math2, Math4");
as per http://www.mozilla.org/projects/mathml/fonts/
This gave me run time errors

WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file nsFontMetricsXft.cpp, li\
ne 2126
###!!! ASSERTION: something is probably wrong somewhere: '1000 != count', file \
nsMathMLChar.cpp, line 2242

5) TeX CM truetype fonts

In bug 176290 comment #12 jshin suggests using truetype TeX CM (and other,
I assume) fonts. I'll give that a go tommorrow.



    
    

    
  
Does Mozilla-Xft unify core Type1 fonts and TrueType fonts? I understand it is
an exclusive situation here. That is, only the _TrueType_ TeX/Mathematica4.1
fonts are relevant for Xft-enabled builds. The link
http://www.mozilla.org/projects/mathml/fonts/ doesn't yet go into these
subtelties since the Xft support isn't yet in.

    
    

    
  
Thank you for testing.  Mozilla-MathML only works with Mathematica 4.1
fonts. 4.1 fonts and 4.2 fonts are  different not only in names but also
in encodings. As you noticed, type1 TeX CM fonts don't work either.
Their encodings are different from truetype TeX CM fonts. 'Linux' at
MathML project page refers to 'Mozilla-X11core fonts'(because that's the
only released version of Mozilla for Linux that supports MathML).  As far
as fonts are concerned, Mozilla-Xft with bug 176290 patch applied is the
same as Mozilla-Win (that is, you have to use truetype fonts). As for
Symbol font,  It'll work if you have truetype Symbol font...  Where to
get it? Well...
                                                                               
                
Actually, your posting raised an interesting possibility that I never
explored. A workaround or two I had to use for Mathmatica/Symbol fonts
might not be necessary if their type1 version can be used. As for TeX CM fonts,
I think type1 cannot be used in any case for Xft and truetype fonts have to 
be used.


    
    

    
  
> A workaround or two I had to use for Mathmatica/Symbol fonts
> might not be necessary if their type1 version can be used.

  I experimented with Mathematica type1 fonts and Symbol type1 font(that comes
with Adobe acroread).
I wrote the above after looking at TeX CM type1 and Symbol type1 and thought that
Mathematica type1 fonts are similar to Symbol type1. It turned out that they're
similar
(structurally) to TeX CM type1 fonts so that they cannot be used either.
However, Symbol type1 font can be used. In that case, you have to remove these
two lines
for Symbol font in fontEncoding.properties file.

encoding.symbol.ttf = Adobe-Symbol-Encoding
encoding.symbol.ftcmap = apple-roman

Both fontconfig and freetype synthesize a Unicode cmap (from PSNames) for Symbol
type1 
font and Mozilla doesn't need to map Unicode to font-custom encoding. 

I looked for Symbol type1 font (that I thought was included in ghostscript) on my
system, but couldn't find it. When I find it, I'll try to see if it works the
same way
as Symbol type1 font from Adobe.

In summary, you have to use Mathematica 4.1 TTFs, TeX CM TTFs(from Bakoma),
MathMT TTF
and Symbol T1(from Adobe)

    
    

    
  
> ... Symbol type1 font included in ghostscript) ... I'll try to see if it works the
> same way as Symbol type1 font from Adobe

  It's donated by URW and its filename (in gs 7.05) is s050000l.pfb. It appears
that it's a perfect replacement for Adobe Symbol type1. H
Its family name is not 'Symbol' but 'Standard Symbols L'. I couldn't manage to
'force' fontconfig to return it when requested for 'Symbol' with the name
'Symbol'. Of course, editing fonts.cache file will work, but ....  What I tried
in ~/.fonts.conf
is as following:

 <alias>
        <family>symbol</family>
        <prefer>
                <family>Standard Symbols L</family>
        </prefer>
</alias>
 
<match target="font">
     <test name="family">
       <string>Standard Symbols L</string>
     </test>
     <edit name="family" mode="assign">
       <string>symbol</string>
     </edit>
 </match>


    
    

    
  

      
      
      
      

        Attached image
          
        MathML in Action page
        — 
      

    


  

    
    

    
  
I've managed to get a combination of font settings which pass the torture test.
However, when I resize the font from 12 pt to 14 pt one of the divisor
characters becomes a "domino".  

The screen shot in attachment
http://bugzilla.mozilla.org/attachment.cgi?id=122677&action=view of the MathML
in  Action page (also) shows a domino for the divisor character, this time in
the exponent in the final expression. And there is a domino for another
character in the same expression (see the screen shot of the original at
http://www.mozilla.org/projects/mathml/screenshots/start.gif). 

Hopefully just a bit more font tweaking ...


But it



    
    

    
  
The divisior is shown with EFC9 inside a box because apparently Mozilla-MathML asks
for Math2-Bold(Math2Mono-Bold) instead of Math1 with weight Bold (Math2Mono with
weight Bold).
As I mentioned in comment #1, fontconfig regard math2/math2b (math2m/math2mb) as
having
the same family, Math1 (Math1Mono) with different weights. Therefore, when asked for
Math1-Bold or Math1Mono-Bold, fontconfig returns 'null'. I tried tweaking
~/.fonts.conf
to work around this problem (as with URW Standard Symbols L as mentioend in
comment #42.
actually editing rules I tried for this case were more complicated than that in
comment #42),
but couldn't make it work. 

To rbs, can you make MathML engine ask for MathN (MathNMono) with the weight set
to Bold
instead of asking for MathN-Bold and MathNMono-Bold? 

To keith, what set of editing rules do we need in situations like this (or
comment #42)?

As for U+225D(Equal To By Definition), the character is not covered by MathML fonts
(TeX CM, Mathematica, Symbol, MT Extra) and should come from other fonts on your
system. It appears that none of fonts on your system has it. Why don't you install
some fonts with a broader coverage? 

BTW, TeX CM fonts don't have the problem (with Bold) so that MathML pages will
be rendered fine if you choose 'TeX style' in View|Use Style. 

    
    

    
  
re: MathN (MathNMono) with weight bold vs. MathN-Bold and MathNMono-Bold

The MathML is already doing the first. I suspect that there might be some
confusion elsewhere in the font association. Suggesting to comment out the
entries for MathN-Bold and MathNMono-Bold in fontEnconding.properties to see
what happens.

    
    

    
  


  
rbs, thank you for the answer and sorry for my misdiagnosis. 

Now this is something to look at.

In the log, Math2 was requested once and fontconfig returned it at the top of
'matched' font list.
Math4 was requested twice and came up at the top of the list both times. In
both fonts, U+EFC9 
(the PUA char for '/' stretch glyph in Math2) was searched for. When it's
searched for in Math2, 
it's found in Math2 (search for the string 'c> found in' in the log. needless
to say, it does have U+EFC9). 
However, apparently, it's not used in drawing '/'. When it's searched for in a
set of fonts whose 'zeroth'
member is Math4, it's found in the 7th	font in the set that happened to be
'TITUS Cyberbit'. 
On Geoff's computer, no font covers U+EFC9 other than Math2 so that it's NOT
found in
a set of fonts returned by fontconfig when asked for 'Math4' and drawn with
'EFC9' inside
a box(unknown glyph fallback).

The question is why on earth Math4 was used to draw U+EFC9 ('/' strech glyph in
Math2) instead of
Math2.

    
    

    
  


  
Sorry attachment 122729 [details] was the wrong file. I should have uploaded
this one. Basically, it has <mo>/</mo> with the stylesheet set to
use Mathematica fonts.

        Attachment #122729 -
        Attachment is obsolete: true

    
    

    
  
'/' problem was also reported (on Mozilla-X11core fonts) in bug 120198. 
(see attachment 92558 [details] : Screenshot showing black boxes instead of "/" symbols).
The patch for bug 118600 was supposed to address various issues in bug 120198, 
but didn't seem to fix '/' problem. I'll check with Xft turned off.


    
    

    
  
Some prefs are needed to activate the patch for bug 118600 for '/'. It works on
a character-by-character basis. Remember the less-or-equal sign '<=' problem
with CMSY10? That was fixed by hard-wiring some default prefs for it following
the fix for bug 118600. Once that problem was well understood, it was clear that
hard-wiring some default prefs was justified.

This one is blurred, though. Let's try to understand what is going on before
resorting to the fallback solution (if it works).

    
    

    
  
I think the problem with the solidus is that the mathfontMath4.properties and
the encoding/math4.html are out of sync.

Specifically, the solidus character is commented out in encoding/math4.html

-0xD1  0x002F:0  #Forward slash (solidus)
-0xD2  0x002F:1  #These are much smaller than those in Math2
-0xD3  0x002F:2
-0xD4  0x002F:3
-0xD5  0x002F:4

but the solidus appears in mathfontMath4.properties

\u002F = \uFFFD\uFFFD\uFFFD\uFFFD\u002F\uF8FF\uF8FF\uF8FF\uF8FF # /

When I commented out the above line my solidus problem was fixed.

I also tried running encode.pl (after some small Windows->Unix 
path mods). I get an error 

ERROR *** Duplicate: 0x40 0x21BF:0 0x2960:T vs. 0x60 0x2191:0 0x2191:T 0x21A5:T
0x295C:T 0x2960:T

I further moded (modded?) encode.pl to not die but just output the errors it
runs to completion and the math4-properties.txt does not have the solidus in it.

I tried the torture and other tests, and the single solidus test from Jungshik
Shin, using different font size preference, and different Text Zooms, and had no
solidus problems.

So now just about all the MathML tests I've tried work - bar the glyphs I dont
have installed (many). (The U+2061 domino occured reasonably often, but there
are many others, operators in particular). So I need to know what other fonts to
install to increase my coverage.

I'm seeing one other small problem with the stretchy test case 
file:///home/gl/mozilla/layout/mathml/tests/stretchy.xml

And now that I look really close at the torture test things arent pixel perfect
(never ending story I imagine), but they sure look a whole lot better than the
aliased font version :-)




    
    

    
  
> This one is blurred, though

 Yes, this one is really strange. It seems like for some mysterious reason Math2
is asked for once and then later Math4 is asked for for U+EFC9 (that appears to
have been correctly identified by MathML as the PUA code point in Math2 to
render / in that occasion.)

 BTW, setting base font for U+002F to Symbol didn't help. 

I downloaded Mozilla 1.4b and tested it(Mozilla-X11core-FT2. It's been a while
and I would never return to this again except for testing :-) ) with type1
fonts(TeX CM, Mathematica 4.1, Symbol). In my minimalistic test case(attachment
122730 [details]), I had exactly the same problem. However, in mathml torture page,
everything got rendered correctly. ....

 Geoff. Thank you for the tip. I considered looking at those files, but haven't
because Mozilla-Win should have the same symptom if there's a problem with them.
Well, some math fonts have behaved in unexplicable (platform-dependent) ways in
the past :-).. I'll try what  you did. 

 As for fonts with wider Unicode coverage, google 'Alan Wood Unicode font'  and
the first hit will be  his comprehensive list of fonts with varying ranges of
Unicode coverage.

    
    

    
  
I think Geoff nailed down the cause. Thank you. Otherwise I'd be still torturing
my harddisk :-) I was sorta fooled by platform-depedent behaviors. Because the
way glyphs are searched for are platform-dependent/toolkit-dependent, on some
platforms(e.g. Windows) Mozilla is handed the glyph of U+EFC9 from Math2 even
when it asks for U+EFC9 in Math4 that doesn't cover U+EFC9(according to
x-mathematica-4 encoder). While on other platforms(Xft or Mozilla-X11coreFT2),
that's not the case (when Math4 is asked for, Math2 is not in the list of fonts
in which glyphs are looked for). The size-dependent behavior is maybe explained
by that U+EFC9 is for a larger (stretched?) version of U+002F.

BTW, can you tell me what problems you found in 'Math Stretch test case'? I
found the bottom part of a stretched integral sign and  the right part of a
stretched right arrow don't get quite aligned with the middle part(glue). Is it
what you observed? I think two thick  bars are rendered  as they should be
(they're given thickness of 30 and 29, respectively). 

    
    

    
  


  
When using large font sizes (36 point, but seems like around 24 c.f. other
environments (Latex)) (some?) subscript and superscript characters dont seem to
scale.

    
    

    
  


  
I've noticed some distinct notches in stretchy characters. One is the square
root sign at some font sizes. The screen shot shows a magnification of the
notch - but it is visible at normal size (originally 12 pt). I see a similar
notch in the underbar (?) of torture test 22.

    
    

    
  
Comment on attachment 122751 [details]
stretchy.xml with black holes

Did you mean very thick bars between a and b (next to 'in binomial formulars')
and inside a long integral sign (before x ---->(maps to) y)? They're rendered
as they should be as I wrote in my previous comment. If you mean U+2062, you
will set it rendered with a real glyph by installing fonts like
Code2000(http://home.att.net/~jameskass) and Titus(see the font section at 
http://www.unicode.org/onlinedat/resources.html)
Hmm. actually, U+2062 is not supposed to be visible. I'm wondering why it's
passed down to the renderer (on my Linux box, it's rendered with dotted 'X'
enclosed by a dotted box. )

    
    

    
  
Comment on attachment 122751 [details]
stretchy.xml with black holes

Did you mean very thick bars between a and b (next to 'in binomial formulars')
and inside a long integral sign (before x ---->(maps to) y)? They're rendered
as they should be as I wrote in my previous comment. If you mean U+2062, you
will set it rendered with a real glyph by installing fonts like
Code2000(http://home.att.net/~jameskass) and Titus(see the font section at 
http://www.unicode.org/onlinedat/resources.html)
Hmm. actually, U+2062 is not supposed to be visible. I'm wondering why it's
passed down to the renderer (on my Linux box, it's rendered with dotted 'X'
enclosed by a dotted box. )

    
    

    
  
Yes in relation to stretchy.xml and comment 55 I was referring to the two thick
bars which in comment http://bugzilla.mozilla.org/show_bug.cgi?id=128153#c54 you
said were actually rendering correctly. So no problem there.

The stretchy.xml screenshot does show a notch on the "aa+bb" overbar. It sort of
looks as though the straight horizontal bar used as the middle part is of a
different thickness to the two glyphs either side.

I'll have a look at installing extra fonts to get wider coverage. 

    
    

    
  
re comment #56. I can't reproduce it. Even at 600%, subscripts and 
superscripts scale well for me.

As for the apparent misalignment between glues and right/bottom part
I wrote about, some of them seem to be due to round-off error, 
anti-aliasing and possibly font-metric problem. I don't see the mismatch 
in thickness  mentioned in comment #60 (in the overbar over aa+bb),
but I do see similar problems in other stretchy glyphs (in some 
cases) depending on the magnification. The dependency on the magnification 
suggests that this also has to do with round-off error/ separate 
anti-aliasing of component glyphs. Some mismatches are persistent at various 
magnifications, which may be attributed to genuine glyph-metric issues in 
fonts used.

As for very thick bars, in case it was not clear, the reason they're 
supposed to be rendered that way is  that they're marked-up that way 
(with linethickness specified to  be 30 and 29) perhaps to test that
'attrib'. 


    
    

    
  
re small subscript/superscripts in comment 56 (resolved)

I was speaking to Roger (same country and time zone) who suggested do a page
reload. Fiexed (workaround) the problem.(Maybe a separate bug on Text Zoom, but
not this bug).

re notches is some stretchy characters in comment 57 and comment 60 (resolved)

Pixel perfection and perfect joins at all font sizes are (I imagine) a high goal
for the future. A couple of notches and kinks in stretchies is fine. 

re installing fonts (resolved)

I havent (yet) installed a set of fonts increase my coverage, so I'm still
getting some dominoes. More generally, I suspect other Linux/*nix users will
seek specific guidance on a list of fonts to install once this patch goes in.
But that guidance is above from Jungshik, at least in terms of places to go (so
many choices though :-)).
 
So from my perspective, all problems resolved and works for me with the patch
from 176290. Antialiased MathML looks great (some screenshots to come) Thanks. 

Looking forward to (hopefully) patch checkin for 1.4f.

    
    

    
  


  

    
    

    
  
Comment on attachment 122830 [details] [diff] [review]
patch to correct the typo (@see comment 52)

asking a= for clearance to correct a mismatch in the mathfont association of
the solidus '/'.

        Attachment #122830 -
        Flags: superreview+

        Attachment #122830 -
        Flags: review+

        Attachment #122830 -
        Flags: approval1.4?

    
    

    
  
re: comment 62
>So now just about all the MathML tests I've tried work - bar the glyphs I dont
>have installed (many). (The U+2061 domino occured reasonably often, but there
>are many others, operators in particular). So I need to know what other fonts to
>install to increase my coverage.
...
re: comment 59
>Hmm. actually, U+2062 is not supposed to be visible. I'm wondering why it's
>passed down to the renderer (on my Linux box, it's rendered with dotted 'X'
>enclosed by a dotted box. )

When was the last time you made a trip to nsTextFrame? It is lot easier to turn
that into nothingness in the font engine than higher up.

On GfxGTK with core fonts and GfxWin, we do what is called "transliteration"
which helps to mitigate this "domino effect". I just filed bug 204993 for the
support of transliteration in Xft. MathML can make better use of that through
bug 119664.

    
    

    
  
> When was the last time you made a trip to nsTextFrame? 
  
Not long ago :-) (see bug 192088 and bug 204286 and other CTL bugs)

> It is lot easier to turn that into nothingness in the font engine 
> than higher up.

  Thank you for opening up my eyes to this interesting new issue.
I'll further comment on it in bug 204993. 

    
    

    
  
Comment on attachment 122830 [details] [diff] [review]
patch to correct the typo (@see comment 52)

a=sspitzer

        Attachment #122830 -
        Flags: approval1.4? → approval1.4+

    
    

    
  
Comment on attachment 122830 [details] [diff] [review]
patch to correct the typo (@see comment 52)

this one is now checked in, taking it off the radars.

        Attachment #122830 -
        Attachment is obsolete: true

    
    

    
  
I downloaded the nightly source from 14 May and applied the patch from
bug #176290 (attachment 120830 [details] [diff] [review] I think it was) and compiled it with Xft
and GTK2 on RH9. The result looks better than ever before! There are however
still a few issues, mainly about spacing and the complete missing of greek
characters. I have installed the TrueType versions of Mathematica 4.1 and
TeX fonts.

    
    

    
  
> the complete missing of greek

Thanks for testing. Do you have either 'Symbol' (from Adobe : included in Adobe
Acroread) type1 font or 'Symbol' truetype font installed? See comment #41 about
using the former. 


    
    

    
  
what's the status on this?

    
    

    
  
This one depends on bug 176290. It didn't make in 1.4 release, but it's fixed on
the trunk (for 1.5 development). So, I'm marking this as fixed. I'm currently
waiting for 1.4.1 approval for my patch to fix bug 176290 in 1.4.x branch. If I
get a green light, MathML will also be supported in 1.4.1 branch. 

Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
I still get the following message

To properly display the MathML on this page you need to install the following fonts:
CMSY10, CMEX10, Math1, Math2, Math4, Symbol.

on http://www.mozilla.org/projects/mathml/ with build:

  Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.5a) Gecko/20030708

though the fonts are installed (and the above web page worked on non-Xft
versions of Mozilla).

    
    

    
  
Math fonts for non-Xft build don't work for Xft-build. 

Here's the summary of comment #41:

In summary, you have to use Mathematica 4.1 TTFs, TeX CM TTFs(from Bakoma),
MathMT TTF and Symbol T1(from Adobe as included in Acrobat)



    
    

    
  
Do we have urls for all those fonts so we can point people at them?  This could
become a FAQ.

    
    

    
  
rbs, could you update the MathML project page
(http://www.mozilla.org/projects/mathml) to reflect the fact that Xft-build now
supports MathML with truetype fonts (instead of T1 fonts except for Symbol that
can be either T1 or TTF [1])? 
As you may know, for Xft build, just throwing fonts into one of font-search
paths (specified in fonts.config) is about the only thing necessary (i.e. no
more mkfontdir, xset fp+ ....) 

[1] To use Symbol TTF (not usually available on Linux), the commented-out lines
for it in fontEncoding.properties have to be 'activated'. 

    
    

    
  
As I have written already, mozilla 1.4b with the patch works quite well.
There are few points however:

1. Some symbols look a little out of place. For example &Union; is taken
from Lucida Sans Unicode and is a too bold. &cup; on the other hand looks
quite well, but first, is &Union; is the right symbol to use and &cup; has
no entry as an operator (infix...). Also the selection of the normal
and big versions of &Union; doesn't always work correctly.

It is quite difficult to get all the fonts needed together. There should be
a downloadable package containing all the necessary fonts.

2. The operator \u2282 (subset of) has no entry in mathfont.properties.
I included the line:

operator.\u2282.infix = lspace:thickmathspace rspace:thickmathspace

In fact, this operator doesn't seem to be defined in the MathML spec either,
which is strange.

3. Large parantheses appear broken at the joints of the segments.

4. The horzontal bar of <frac> is a little too thick.

All in all however, it is usable, and we use Mozilla in our web-based
mathematics course.

    
    

    
  
Concerning comment #76, what is fonts.config?

I've added
  dir "/usr/share/texmf/fonts/type1"
to /etc/X11/XftConfig in order to get the CM fonts into Mozilla, but this
doesn't change anything.

    
    

    
  
Do you have Symbol T1 font in  /usr/share/texmf/fonts/type1? I don't think you
do. Symbol T1 font comes with Adobe Acroread and you have to make it available
to fontconfig/Xft. 
 
As for fonts.config, you must have an old version of Xft/fontconfig. Anyway,
fonts.config is what used to be Xftconfig. 

    
    

    
  
I have a directory /usr/share/texmf/fonts/type1/urw/symbol, which contains
"usyr.pfb" (as the only file -- perhaps fonts.dir would be needed too). This
file says:

%!PS-AdobeFont-1.0: StandardSymL 001.005

Is it OK?

But Mozilla complains for *all* CMSY10, CMEX10, Math1, Math2, Math4, Symbol,
though I have cmsy10.pfb and cmex10.pfb (and fonts.dir) in
/usr/share/texmf/fonts/type1/bluesky/cm.

    
    

    
  
This is the last comment I'm gonna make about fonts because everything that
needs to be answered has already been answered. 

1. Mozilla-Xft does NOT work with Type1 fonts (except for Symbol). You MUST
install __TRUETYPE__ fonts (Mathematica 4.1 and Computer Modern).   

  - CM TTFs are available at
http://www.mozilla.org/projects/mathml/fonts/bakoma/texcm-ttf.zip

  - Mathematica 4.1 (not 4.2) TTFs are available at 
http://support.wolfram.com/mathematica/systems/windows/general/latestfonts.html
    (I guess 'unzip' works with the self-extracting '*.exe'. If not,
     you have to extract fonts on Windows and copy to Unix/Linux)
 
  - MT Extra TTF is at
   http://www.mathtype.com/support/fonts

2. As I wrote in comment #42, URW (in whatever filename) Symbol doesn't work
unless you edit the font file(rename it as 'Symbol') or fonts.cache to 'deceive'
Mozilla to believe it is 'Symbol' instead of 'Standard Symbols L'. There might
be other ways, but I haven't figured it out yet. 

  In the meantime, you have to use Adobe 'Symbol' Type1 font (included in
Acroread) [1] 

3. Put fonts mentioned in #1 and #2 into a directory (say,
/usr/local/share/fonts/TTF or ~/fonts/TTF) and add the directory to fonts.conf
or Xftconf. [2]

4. Run mozilla and enjoy !

[1] 'Symbol' truetype font also works if you remove the comment for the
following lines in fontsEncoding.properties file (in $MOZILLA_HOME/res/fonts)
----------------
#encoding.symbol.ttf = Adobe-Symbol-Encoding
#encoding.symbol.ftcmap = mac_roman
------------------

[2] With Xft and fontconfig, you can finally say goodbye to 'fonts.dir',
'fonts.scale', 'fonts.alias', mkfontdir, 'xset fp', etc. Just throwing fonts
into a directory and adding the directory (if not already in the fontconfig
search path) to fonts.conf (or Xftconfig) suffice. 

    
    

    
  
I now have:
  * a directory /usr/local/share/fonts/type1/Acrobat containing Symbol (type1
font from Acrobat Reader),
  * a directory /usr/local/share/fonts/truetype/Mathematica containing the
Mathematica .ttf fonts (the exe file could be unzipped),
  * a directory /usr/local/share/fonts/truetype/texcm-ttf containing the 4 CM
.ttf fonts.
I couldn't get the MT Extra TTF fonts, though (Windows only installer).

In /etc/X11/XftConfig, I added:
dir "/usr/local/share/fonts/type1/Acrobat"
dir "/usr/local/share/fonts/truetype/Mathematica"
dir "/usr/local/share/fonts/truetype/texcm-ttf"

But when running Mozilla and opening the MathML start page, I still get the same
error.

    
    

    
  
In response to comment #82, maybe /etc/X11/XftConfig is the wrong file to be
adding the directories to.  I downloaded a mozilla-firebird+xft build and found
that it *never accesses* that file.  Instead it reads /etc/fonts/fonts.conf and
/etc/fonts/local.conf.  So I suggest adding lines such as

    <dir>/usr/local/share/fonts/type1/Acrobat</dir>

to /etc/fonts/local.conf and seeing if that works.  When I do that I don't get
any missing-fonts messages.

"ls -lu" is your friend.

    
    

    
  
Thanks, this is much better. However, I still get an error message concerning
Math1, Math2, Math4. A "ls -lu" shows me that in
/usr/local/share/fonts/truetype/Mathematica, only Mathematica3.ttf is read by
Mozilla! Why?

    
    

    
  
There is no file Mathematica3.ttf in the 4.1 Mathematica font set, only in the
4.2  Mathematica font set.  You need to use the 4.1 Mathematica fonts.

    
    

    
  
(In reply to comment #81)
> 2. As I wrote in comment #42, URW (in whatever filename) Symbol doesn't work
> unless you edit the font file(rename it as 'Symbol') or fonts.cache to 'deceive'
> Mozilla to believe it is 'Symbol' instead of 'Standard Symbols L'. There might
> be other ways, but I haven't figured it out yet. 
> 
I've tried setting the font.mathfont-family pref to use "Standard Symbols L"
rather than "Symbol", and made a copy of the mathfontSymbol.properties file as
mathfontStandardSymbolsL.properties and changing the line:

mathfont = Symbol

to

mathfont = Standard Symbols L

not sure if it actually works though :D

    
    

    
  
You guys like to tweak things :-)
One thing that you missed is in mathfont.properties:
font.mathfont-family = CMSY10, CMEX10, Math1, Math2, Math4, MT Extra, Symbol

which you force to:
font.mathfont-family = Standard Symbols L

or using the pref:
pref(font.mathfont-family, "Standard Symbols L")

[either setting will stop the other fonts on the initial list from being used --
therefore it allows you to confirm whether your tweaking works -- if you still
see large parenthesis, brackets, and other stretchy characters from the Symbol
font.]

As you can see, there are several occurrences of "Symbol" in
mathfont.properties. That's why it is much easier just to alias in one place --
if you can (as comment 42 attempted).

----------
IMPORTANT: You can forget about the Symbol font--if you have the other fonts... 
Don't become obsessed about it. You are not missing anything (that's why you
couldn't tell if your tweaking actually worked or not).

EXPLANATION: The MathML engine needs some characters from the Symbol font, but
just like the character 'a' can be found in several fonts, the characters in the
Symbol font can be found in the other fonts.

It is for *first-time* users (with no math fonts yet...) that their default
installed Symbol font is useful. Indeed, the thinking is that when they install
the browser, the MathML engine uses their Symbol font and they at least see
something, have a good first impression of the MathML support, and feel
_encouraged_ to try the dreaded steps of installing the other fonts. Then, when
the TeX fonts and Mathematica fonts are installed, their Symbol font becomes
unimportant because the other fonts have even more characters.

    
    

    
  
(In reply to comment #87)
> You guys like to tweak things :-)
> One thing that you missed is in mathfont.properties:
> font.mathfont-family = CMSY10, CMEX10, Math1, Math2, Math4, MT Extra, Symbol
> 
> which you force to:
> font.mathfont-family = Standard Symbols L

heh sorry I wasn't clearer, what I did was change it from 
"CMSY10, CMEX10, Math1, Math2, Math4, MT Extra, Symbol"
to
"CMSY10, CMEX10, Math1, Math2, Math4, MT Extra, Standard Symbols L"

> As you can see, there are several occurrences of "Symbol" in
> mathfont.properties. That's why it is much easier just to alias in one place --
> if you can (as comment 42 attempted).
tried lots of ways using fontconfig, but moz keeps complaining that there's no
Symbol font. My guess is that the mathml code isn't checking for aliases?

> 
> ----------
> IMPORTANT: You can forget about the Symbol font--if you have the other fonts... 
> Don't become obsessed about it. You are not missing anything (that's why you
> couldn't tell if your tweaking actually worked or not).
Heh, no wonder, so I should be able to safely remove the Symbol font from that list.

    
    

    
  
> My guess is that the mathml code isn't checking for aliases?

It isn't supposed to. The font engine/server should shield that.

What about opening another bug where we can consider configuring the default
mathfont properties files to support 'Standard Symbols L' since this seems a
common font.

    
    

    
  
(In reply to comment #89)
> > My guess is that the mathml code isn't checking for aliases? 
> It isn't supposed to. The font engine/server should shield that.

Adding the following line to ~/.fonts.conf (or /etc/fonts/local.conf)
seems to work (thanks to Mike Fabian of SuSE Linux)

  <match target="pattern">
    <test name="family">
      <string>symbol</string>
    </test>
    <edit name="family" mode="append" binding="strong">
      <string>Standard Symbols L</string>
    </edit>
  </match>

> What about opening another bug where we can consider configuring the default
> mathfont properties files to support 'Standard Symbols L' since this seems a
> common font.

I just filed  bug 236880.


          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: