Need to get the MathML fonts working with Xft. Bug #35236 has some good hints.

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.

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

Thanks, Chris. I uploaded a patch to bug 176290 as you noticed. Not yet working correctly, but appears promising..

better than before(with a sign change in GetBoundingMetrics), but still something is wrong...

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.

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.

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>^<i>jif</i></span><dot>.</dot><br /> HTML: <span><i>jif</i>^<i>jif</i></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>^<i>jif</i></span><dot>.</dot><br /> HTML: <span><i>jif</i>^<i>jif</i></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>^<i>jif</i></span><dot>.</dot><br /> HTML: <span><i>jif</i>^<i>jif</i></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)

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

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

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.

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

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

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.

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.

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.