Closed Opened 20 years ago Closed 10 years ago

# [trk] Rendering errors on MathML demos

Not set
normal

RESOLVED FIXED

## Attachments

### (28 files)

 3.21 KB, image/png Details 5.63 KB, image/jpeg Details 12.78 KB, image/png Details 968 bytes, image/gif Details 2.27 KB, image/png Details 33.07 KB, image/png Details 1.66 KB, image/gif Details 19.28 KB, image/jpeg Details 22.20 KB, text/xml Details 20.33 KB, image/png Details 20.30 KB, image/png Details 3.08 KB, image/png Details 49.50 KB, image/png Details 16.41 KB, image/jpeg Details 18.03 KB, image/png Details 105.19 KB, image/png Details 64.14 KB, image/png Details 6.21 KB, text/xml Details 71.87 KB, image/png Details 7.74 KB, image/jpeg Details 103.92 KB, image/png Details 6.31 KB, image/png Details 7.09 KB, image/png Details 3.13 KB, image/png Details 54.54 KB, image/png Details 10.17 KB, image/png Details 1.22 KB, image/png Details 843 bytes, patch karlt : review+ karlt : checkin+ Details | Diff | Splinter Review
Opening this bug to collect glitches that may be seeing on MathML demos, so that
fixing these would allow to polish the MathML engine even more.
Summary: Rendering errors on MathML demos → [trk] Rendering errors on MathML demos
Noted in the demo of mfrac that the thick line (linethickness="1pt") seems to
show up only in those cases where the fraction is in display mode
http://www.mozilla.org/projects/mathml/demo/mfrac.xhtml

In the MathML Torture Test, #15 appears as 2^2^28 in the TeX column and 2^2^2^x
in the MathML column. I'm running the latest nightly Win32 build, 2002031403.
However, his would appear to be a bug in the demo -- I'm reportingit here as it
seems the most appropriate place to do so. 
Math operator page <http://www.mozilla.org/projects/mathml/demo/mo.xhtml>,
stretchy fences demo: forward slash (/) stretches just fine, but backslash (\)
doesn't stretch at all.  It just remains at normal display size.
Lowercase letters inside math tags are rendered in Greek on all of the demo
pages.  For example, a (not &alpha;) becomes alpha, z becomes zeta.  I guess
it's poor font choice.  I'm running Solaris 2.6 build 2002031500.
iraqispy: You probably have a buggy "Symbol" font.
Comment on attachment 75210 [details]
A cropped screenshot of the mozilla window showing exmaple #13 on the mathml torture page

which platform/OS?
I had a problem resembling Jason's (comment #6) that disappeared after
re-installing fonts.

Noticed the integral sign is rendering incorrectly with build 2002032503 on
Windows 98 on the page http://www.mozilla.org/projects/mathml/demo/basics.xhtml

Screenshot will follow.
Attached image half integral
It's probably a font error.
OS: WXP
Moz: Mozilla RPC 1
I'm running Mozilla 1.0RC3 on Solaris 8 and have the fonts
Math1-4, cmex10 and cmsy10 installed.

Example 14 and 23 have the same error: The first parenthesis in example 14 is
missing and so are the smaller left parenthesis in example 23.

Example 28 looks a bit strange, I'll supply a screenshot.
Example 28b is intentional (although the rendering should perhaps be improved).
Its purpose is to warn authors not to use that markup if what they want is
really 28a (click on them to see the different markups in 28a vs. 28b).

Got a screenshot for Example 14 and 23?
Numbers and operators fall out of root signs
Attachment #88586 - Attachment description: #13 screenshot → #13: Numbers and operators fall out of root sign
For me on http://www.mozilla.org/projects/mathml/demo/texvsmml.xml tests 5, 8
and 18 show the slash symbol as a solid block (this is with linux on i686 using
mathematica and tex fonts).
>this is with linux
which distro?
RedHat 7.3, Mozilla 1.1b
Your problem looks like bug 149566. I suggest you try experimenting what I said
in bug 149566 comment 4 with the Symbol font in general, and filing a bug
against GFX Compositor.
This looks rather different - I'm not getting greek characters everywhere -
everything else looks fine. I'll include a screenshot to demonstrate.

On Mozilla 1.1, Windows XP, with TeX and Mathematica fonts installed, everything
rendered correctly except for the <= (less than or equal) signs, which came out
as square boxes.
Still broken on Mozilla 1.1 on Linux with Mathematica and Tex fonts for me.
Depends on: 161155
I'm confirming the problem mentioned in comment 23 on both Windows 2000 (GDI+,
SVG and MathML build from yesterday) and Linux (ID:2002121021) builds. All the
other tests look OK (minus a few missing glyphs on my system).

re: comment 23
should be fixed now, it was a regression - see bug 191529.
The less-than-or-equal symbols in the subscript location under the large
(http://www.mozilla.org/projects/mathml/demo/texvsmml) are not rendered --
appear as missing-symbol boxes.  This is in Mozilla 1.3 (under Windows XP Pro
SP-1) with the stated fonts installed:	the 4 BakoMa cm fonts; the various
Wolfram "Math" (and even the newer "Mathematica") fonts; and MTSymbol and
MTExtra.
Was also reported in comment 21. I see no problem on Win2K. I think something
fishy is happening on WinXP with the CMSY10 font in particular. Try using the
Character Map (from Start Menu -> Programs -> Accessories -> System Tools ->
Character Map) to see the glyphs that are in the fonts. If everything is alright
you should get this:
http://www.mozilla.org/projects/mathml/fonts/encoding/cmsy-ttf.gif
(note that '<=' can be seen at position B7).
MacOSX 10.2.4 with the Mathematica Fonts installed.

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

Tests 5,8,13,16,18,19,21,22 are broken: "/", stretchy integral sign, square-root
and over- and under-braces not rendering correctly. See <a
href="http://bugzilla.mozilla.org/attachment.cgi?id=118866&action=view">attachement
118866</a>.

Using:
user_pref("font.mathfont-family", "Math1, Math3, Math5");

Things are a little better: square-root does not render correctly, and over- and
under-braces are not stretchy. See <a
href="http://bugzilla.mozilla.org/attachment.cgi?id=118867&action=view">attachement
118867</a>.
This is the rendering with
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4a) Gecko/20030401
Re: Comment #32. Same as Comment #25:

Square Root line appears as Box:
http://bugzilla.mozilla.org/attachment.cgi?id=109035&action=view

Since you are on Windows, just install the TeX fonts and the problem will go away.
http://www.mozilla.org/projects/mathml/fonts/
Environment: Mozilla 1.2.1 on Solaris 9, with the TeX CM and Mathematica fonts

In Test 9, none of the minus signs appear after adding the fonts (they do
appear if the fonts are not added).

We also see the problem with missing left parentheses in 14 and 23, reported
in comment #11.  We have found that this problem goes away when you tell
Mozilla to use the Mathematica fonts when stretching, by adding the following
to prefs.js:

user_pref("font.mathfont-family", "Math1, Math2, Math4");
old problems:
slash screenshot: http://bugzilla.mozilla.org/attachment.cgi?id=92558
less-or-equal screenshot: http://bugzilla.mozilla.org/attachment.cgi?id=80132

these have been fixed in more recent builds (expected milestone release: m1.4final)

Mozilla 1.3.1, Debian Sid

I installed all fonts needed, as told in
http://www.mozilla.org/projects/mathml/fonts/. The font are served by xfs, seen
by X font managers.
> Mozilla 1.3.1, Debian Sid

That build is too old... and seems to be Xft-enabled. See the troubleshooting
link on the math font page.
unfortunately http://bugzilla.mozilla.org/show_bug.cgi?id=35236#c4 did not help.
Shall I manage to disable xft to render MathML properly ?
I was meaning the thread, no just that single comment. Yes, you have to turn off
Xft for the time being: bug 35236 comment 38.  C.f. also this thread in the
n.p.m.mathml news group: http://groups.google.com/groups?th=cfb805db450d7d65
Environment: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4)
Gecko/20030624 with the Mathematica fonts installed.

I'm seeing some of the problems mentioned in comments #29, #30, and #31 although
not as many probably because my Mozilla build is more recent:

test 13 -- the square root is not rendered correctly (appears as in the
attachment provided in comment #29)
tests 16 and 21 -- the integral is not rendered correctly (appear as in
attachment comment #29)
tests 19 and 22 -- the under and over-braces are not rendered correctly (same as
comment #29)

In addition: test 14 displays an "upper-case phi" instead of a lower-case one.

Also, the Mozilla pop-up window lists the "Symbol" fonts are missing even though
they are installed on my computer.
In mathML torture test #9, minus signs are missing.

I am using Mozilla-1.5b under Solaris 9 for the sparc.

Everything else on that page looks great (except for bugs in the page itself,
as noted for example in Comment #2).
Hi Paul,

We also observed the same problem -- see comment #34 -- and found out that it
comes from the TeX fonts. We haven't found a way to fix it but decided NOT to
install the TeX fonts on Solaris 9. Just having the Mathematica fonts is fine
for most purposes (if you can live with the Mozilla "missing fonts" pop-up window).

Daniel Jamous
re: comment 39
Xft builds now have MathML. No need to turn it off. Apparently, people who try
it vow not to come back to a build without Xft again. However the intl support
is still not in parity with the default trunk build.

re: Daniel & Paul (comment 41, comment 42)
Set the following pref (e.g., in your prefs.js or simply using the handy
about:config, and righ-click from there to define a new string pref)

pref("font.mathfont-family.\u2212.base", "Symbol")

This pref will instruct the MathML engine to use the Symbol font for the minus
sign. U+2212 is the official Unicode minus sign. It looks much better for math
than the text hyphen-minus (-, U+002D). It is what the MathML engine uses
internally for the minus sign. Let me know how it goes, and I might make the
Symbol font the default provider of that glyph. See also mathfont.properties in
your <moz-bin>/fonts/ installation.
Re: comment #43

pref("font.mathfont-family.\u2212.base", "Symbol")

to my prefs.js file, but it just disappeared from the file after running mozilla.
When I changed pref to user_pref, it appeared in the file with \u2212 changed
to Control-R for some reason.  But it still had no effect.

I investigated the bug a little further, and it seems to be the Solaris version
of xfs.  (The X server that ships with Solaris doesn't grok .pf[ab] fonts
itself, so you have to use xfs.  That's what you're doing, isn't it, Daniel?)
Anyway, the Solaris xfs doesn't show the first 32 characters of cmsy10
(and probably also cmex10, but I didn't check).  If I run xfs under Linux,
then I do get those 32 characters.
oops, double the slash... (exit Mozilla before editing prefs, or just enter
about:config in the URL bar to use the built-in GUI to edit prefs)

user_pref("font.mathfont-family.\\u2212.base", "Symbol");
That works ... looks great.  Thanks!
Symbol is now the default for minus (fix in mathfont.properties on 1.6 trunk).
Question for Paul on the minus sign problem on Solaris 9: did you also see a
left parenthesis missing on test 14? Again, this does not appear with the
Mathematica fonts only or by selecting View-->Use Style-->Mathematica

Is there a way to fix this as well? 
> Is there a way to fix this as well?

yes, with a similar pref. But I am getting worried of this. If your TeX fonts
are that bad, you might try the newer versions that are supposedly better.
http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/
> Question for Paul on the minus sign problem on Solaris 9: did you also see a
> left parenthesis missing on test 14? Again, this does not appear with the
> Mathematica fonts only or by selecting View-->Use Style-->Mathematica

No, test 14 looks OK, except that the right parenthesis looks a little
crooked (the upper part is misaligned).

Strangely, selecting View-->Use Style doesn't affect the appearance in
any noticeable way.

Re: Comment #49

>> Is there a way to fix this as well?

>yes, with a similar pref. But I am getting worried of this. If your TeX fonts
>are that bad, you might try the newer versions that are supposedly better.
>http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/

It's not the fonts, it's the font server.  It doesn't serve characters
below 0x20.  If I use a font server running on a Linux machine, everything
looks OK.
> No, test 14 looks OK, except that the right parenthesis looks a little
> crooked (the upper part is misaligned).

I think this problem comes from the Symbol _bitmap_ font. Some of its glyphs
have incorrect metrics. Are you not using a type1 version (the one that comes
with Acrobat Reader), as per your comment in bug 128153 comment 83.


> I think this problem comes from the Symbol _bitmap_ font. Some of its glyphs
> have incorrect metrics. Are you not using a type1 version (the one that comes
> with Acrobat Reader), as per your comment in bug 128153 comment 83.

Indeed, ls -lu indicates that I'm using the bitmap font.  The X server seems to
insist on using that font, instead of the Type 1 font which is ahead of it on
the list.
Addendum to comment 50:

If I use the Solaris xfs, then the TeX fonts are missing the bottom 32 characters.
If I have the X server access the font directory itself, then only character 0
is missing.
If I use a Linux xfs, then all characters are present.
Re comment 49
yes, with a similar pref. But I am getting worried of this. If your TeX fonts
are that bad, you might try the newer versions that are supposedly better.
http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/

font path using:

xset fp+ ...../cm-super/pfb

but there are no fonts.dir and fonts.scale in the directory so the command
fails. I tried creating these files using the script "type1inst" as described at:

http://bugzilla.mozilla.org/show_bug.cgi?id=35236#c4

but that also failed. Not sure what to do next. Any idea?
I don't think you need a fonts.scale.

Here's my fonts.dir:

2

If you're running Solaris, don't forget to run makepsres.

Next time you write please say what version of mozilla you're using.
Paul,

Thanks for the answer. Here's my environment:
Mozilla 1.4 on Solaris 9.

Just to clarify: are you using the cm-super type 1 TeX fonts? These are the ones
I'm currently testing (I already installed the TeX fonts obtained from the
Mozilla fonts page). 
No, just the standard TeX fonts from teTeX 2.0.2 (which are probably identical
to those supplied by mozilla).

But I don't see this as a fonts issue; it's an issue with the Solaris X server
(and also a worse issue with xfs, all Solaris versions so far, plus versions
compiled from older versions of the X Consortium sources).
An error rendering sum using content markup.

Tried in:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031108 Firebird/0.7+
and (not so new Mozilla)
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

Look here:
http://www.w3.org/Math/testsuite/testsuite/Content/SequencesAndSeries/sum/rec-sum1.xml

Error:
Mozilla shows 'a' instead of 'x=a'.
Screenshot of invalid rendering of sum
Re: Comment #58 & Comment #59
It is bug in the Universal MathML XSLT Sheet (UMSS) that does the conversion
from content markup to the presentation markup that is passed onto Mozilla. You
can see it by placing the mouse over the 'x' under consideration, then right
click and pick 'View MathML Source' in the context menu. There is no 'x=a' in
the DOM. Please refer the bug to the W3C Math WG who maintains the UMSS and the
testsuite.
On mozilla 1.5 (mozilla 1.5-3 from Debian testing + mozilla-xft 2:1.5-3).
(I also observed the same problem on Mandrake 9.1 running mozilla 1.4)

I installed the fonts recommended in
http://www.mozilla.org/projects/mathml/fonts/ (in Xft-enabled linux section),
by copying the .ttf's to my ~/.fonts/.

Now I don't have the "missing fonts" messages, but get mangled rendering
(adding the cm fonts cause the attached display. Adding mathematica fonts only
cause greek letters only).

Seems like I have the wrong encoding, but I have no idea how to get encoding
info for xft-tt fonts (fc-list just shows name and style), nor how to force
mozilla to use another encoding.
Amit: confirm that I see the same thing.  I can be worked around by unchecking
"Allow documents to use other fonts".

Is there a separate bug for this?  Is this linux-specific?
jshin, any regression in mozilla+xft? see comment 61 & comment 62.
It is definitely xft (if I set GDK_USE_XFT=0 on Mozilla 1.5 the problem goes
away but fonts are not anti-aliased, the same trick does not work with mozilla 1.6).

Also user_pref("font.mathfont-family", "Math1, Math2, Math4, Symbol"); to use
Mathematica fonts does not fix the problem.

Also note about the "Allow documents to use other fonts" trick -- this behavior
occurs on ALL MathML pages (and the trick works on ALL MathML pages), even if
the page didn't specify a font.

The roman symbol 'x' is coming from the font cmsy (the ttf one on the moz mathml
page)...some other glyphs are coming from some decorative ttf fonts I have
installed.

Screenshot to follow.
there are other font problems in this shot.  I have all fonts installed,
Mozilla does not give the dialog box complaining about fonts.
By default, an Xft build uses Adobe type 1/PS Symbol font that comes with Adobe

If you have a truetype Symbol font (that comes with Windows.[1]), instead, you
have to edit fontEncoding.properties file (that is in res/fonts directory : use
'locate fontEncoding.properties' to locate it) manually.

Anyway, make sure that you have only one of two available to fontconfig.

[1] I wasn't usre whether it's allowed to use it on non-Windows platforms so
that I made Xft builds use type1/PS Symbol fonts by default.
I have installed the symbol font.  As I mentioned, Mozilla does not complain

(0)<mcelrath@draal:/usr/share/fonts> xlsfonts | grep -i symbol
-microsoft-webdings-medium-r-normal--0-0-0-0-p-0-microsoft-symbol
-urw-standard symbols l-medium-r-normal--0-0-0-0-p-0-urw-fontspecific
-urw-symbol-medium-r-normal--0-0-0-0-p-0-urw-fontspecific

Do you have fontEncoding.properties file? Try 'locate fontEncoding.properties'.
What do you get? If it's not installed in $MOZILLA_INSTALL_DIRECTORY/res/fonts (e.g. /usr/lib/mozilla/res/fonts). You have to get it at http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/fontEncoding.properties and put it res/fonts directory. BTW, xlsfonts doesn't tell you anything (we're not dealing with X11 core fonts but the client-side fonts). You have to use 'fc-list' and 'fc-match'. Try 'fc-match --verbose Symbol' and the font file listed is indeed Adobe Postscript symbol. I've found that on Fedora Core 1 (1.4.2 rpm) has fontEncoding.properties file, but it's a broken symbolic link to an unexisting file. A similar thing may have happened to Debian builds. You have to report that to Debian developers. I'm gonna report it to Fedora developers. mozilla.org build doesn't have such a problem as far as I know. You may want to install ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i686-pc-linux-gnu-gtk2-pango.tar.gz  FYI, I've just filed a bug report for Fedora Core1 at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114917 You may file a similar bug report to Debian.  (In reply to comment #68) > You have to use 'fc-list' and 'fc-match'. Try > 'fc-match --verbose Symbol' and the font file listed is indeed Adobe Postscript > symbol. ==> .... and make sure that the font file listed is .......  Missing fontEncoding.properties on debian *and* a M$ symbol.ttf are the problem.
Now when I do fc-match Symbol I get:
Bitstream-Vera-Sans.ttf: "Bitstream Vera Sans" "Roman"
but the math renders fine in both serif and sans-serif.

Can something be done about the M\$ Symbol font problem?  Can mozilla do
something in code to select the proper font?  Can distributions modify their
fontEncoding.properties (or something) so select fonts properly?  Making the
user deal with this is not an acceptable solution.

Also with the Computer Modern fonts there are some spacing problems with large
parenthesis and the like (but I think this is known).  I've added:
user_pref("font.mathfont-family", "Math1, Math2, Math4");
and this improves the look.

BTW don't tell people to get files out of lxr, unless they enjoy hand-editing
the HTML out.  ;)

I will file a bug against Debian.

Thanks for your help.
Netscape 7.1 is also missing the fontEncoding.properties file.

...so then no distributed moz except for the mozilla.org builds can render
MathML...sad...
Re: comments 61,66,68,71 (fontEncoding.properties etc.)

1) Installing fontEncoding.properties solved the main problem - thanks, jshin.
Before I saw comment #68, I copyed the file from Netscape7.0/mswin installation
- but it did not work well (prbly older version. p.s. I'm surprised to hear that
in 7.1 it's missing altogether...). The version from lxr does work.

2) About the symbol.ttf from Windows - it does work fine for me (result looks
much like what you get with the adobe ps Symbol) - provided that I edit
fontEncoding.properties, and uncomment the #encoding.symbol lines, as explained
in the file itself. Anyway - the mathml-torture-page seems to load fine now even
*without any* Symbol font (you get the missing font warning, but the page is
rendered almost the same).
bob, if your'e going to file a bug with debian - maybe they can put a debconf
question to determine if you want to use adobe or ms encoding for symbol (maybe
the script can fill this automaticly if only one of the two is installed).

3) Now I can see math - so I turn my attention to smaller details - I'm
attaching a screenshot...
Re: debconf

Both the Adobe symbol and the windows symbol font are copyrighted and
non-redistributable, so neither is an option for debian.  There is an acroread
in non-free with the font, but the font directory contains a LICFONT.TXT that
explicitly says the fonts are not to be used by any application but acroread.

Where can a free Symbol font be found?

On a related note, the set of instructions so far collected (see
http://mcelrath.org/Notes/MathML) is not sufficent.  It works on Fedora but on
Debian, mozilla is grabbing a non-antialiased font for roman characters.  On
Redhat there are also characters still coming from a non-antialiased font (but
romans are fine).

Can anyone suggest how to figure out which font is giving a given glyph on a page?
Several issues here:

1) The stretchy brackets and det-signs come out as broken lines.

2) <mo></mo> causes "thinspace" (U2009), which is missing, and is rendered as a
box with unicode value inside. Also - I noticed in other places ocurrences of
2061 (ApplyFunction) and 2062 (Invisible Times). Is there some "font" that
provides all these spaces? Maybe you can add some "View" or "Style" option that
would allow ignoring all these missing spaces instead of putting in their
unicode boxes.

3) I noticed that <mi>dx</mi> comes out as roman (not italic) - personally I
like it better this way when representing differentials - but it is different
than the tex rendering shown there - was that intentional?
It'd have better if this discussion had been moved to bug 128153.

> I copyed the file from Netscape7.0/mswin installation
> - but it did not work well

fontEncoding.properties file for Windows is different from
fontEncoding.properties file for Unix, which is why it didn't work.

> Where can a free Symbol font be found?

You can use 'Standard Symbols L' (it's made by URW and GPL'd). In that case, you
have to edit the font file yourself and  change the name to 'Symbol' (not the
name of the font file but 'FamilyName' insdie the file). On Fedora, it's  in
/usr/share/fonts/default/Type1 (the name of the file is s050000l.pfb).

I wish fontconfig aliasing worked for this case, but it didn't when I tried that
in 2002/2003. If it worked, there'd be no need for editing the URW font file.

A moment ago, I  found that URW 'Standard Symbols L' is also included in CUPS as
well. On Fedora, it's in /usr/share/cups/fonts. The name of the file is Symbol
and the family name is 'Symbol' although it's URW's 'clone' of Adobe's Symbol.
With this, you don't have to edit the font file. Just add the path
(/usr/share/cups/fonts) to /etc/fonts/local.conf or ~/.fonts.conf  and you're
all set. (alternatively, copy it to or make a symbolic link to it in ~/.fonts).
Debian can certainly include this font (with the changed name) unless Adobe has
the exclusive right to the name 'Symbol', which is not likely.

re: comment #43
>  However the intl support is still not in parity with the default trunk build.

I wonder where  you got this 'impression'. Then as well as now, the intl
support in Xft build is better than that in the default build in many aspects.

> Netscape 7.1 is also missing the fontEncoding.properties file.

AFAIK, Netscape 7.1 is not an Xft build so that it doesn't need it, which is
why it's not included.

> BTW don't tell people to get files out of lxr, unless they enjoy
> hand-editing the HTML out.

You could have used 'File | Save As' (text file) and the amount of manual
editing would have been a lot less. You could also have just copy'n'pasted from
the screen ;-)

re: http://mcelrath.org/Notes/MathML
> missing from most RedHat/Fedora, and Debian installations

I guess it's the case of 1.4 rpm/deb. I wonder SuSE/Mandrake rpms have the
same problem. Anyway, 1.6 rpm (Xft build) without this issue is available at

ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/yum/
> I guess it's the case of 1.4 rpm/deb. I wonder SuSE/Mandrake rpms have the
> same problem.

It must be the case of any 1.4branch rpm/deb. (tar.gz doesn't have the
problem). The patch to apply is attachment 126983 [details] [diff] [review] (to bug 176290). I forgot to
ask for approval for 1.4branch landing last July. I've just done it (bug 176290
comment #140) so that 1.4.2 release should be all right when released. In the
meantime, distribution builders can apply the patch to their 1.4 builds.

Mozilla inserts too much space between <mi> tags.

http://mcelrath.org/Notes/ITeXLaTeXDifferences

I've beat myself up trying to solve this with CSS, but I don't think it's possible.

Is this the correct place to report this?
Mozilla does not implement lspace and rspace for the <mo> tag?

http://www.dessci.com/en/reference/MathMLTestSuite/testsuite/Presentation/TokenElements/mo/moAlrspace13.html
Verbar (\u2016) doesn't stretch.  However, if you read the Unicode spec. "used
in pairs to indicate norm of a matrix" it seems it should.

Now, DoubleVerticalBar (\u2225) does stretch (and looks like Verbar should).
The Unicode description says "parallel to".  Maybe that shouldn't stretch.
This is debian sarge, Mozilla 1.7.3, using the texcm ttf fonts, Mathematica 4.1

ttf fonts, and the Symbol font which came with the Adobe Acrobat Reader 5.09.
I
had to comment out the lines referring to the symbol font in the
fontsEncoding.properties file to get this to work, but there is a missing
symbol
for empty space (2009 in #17, 21) and a lowered apostrophe appearing in #22.
Hi.
Just to say that Radicals of formula #13 of the torture test don't appear
correctly : they are filled with black rectangles.
Good luck.
the greek alphabet displays as these slanty cryllic characyers
Only a problem in my linux machine. The same page loads fine in Windows!
A <mo accent="true">&macr;</mo> placed over more than one character keeps a one
character length. Correct behaviour : the line should be over all the
characters.
In attachement a PNG image showing the Mozilla output and the LaTeX output
(obtained with the \overline command).

Note that Amaya renders well this accent.

Here is the MATHML code used to generate the PNG image:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<mstyle id="x7-7004r22" class="label"/>
<msub>
<mrow>
<mover accent="false" class="mml-overline">
<mrow>
<msup>
<mrow>
<mi>L</mi>
</mrow>
<mrow>
<mo class="MathClass-bin">&lowast;</mo>
</mrow>
</msup>
<msup>
<mrow>
<mi mathvariant="script">G</mi>
</mrow>
<mrow>
<mo class="MathClass-bin">&lowast;</mo>
</mrow>
</msup>
</mrow>
<mo accent="true">&macr;</mo>
</mover>
</mrow>
<mrow>
<mi>y</mi>
</mrow>
</msub>

<mo class="MathClass-rel">=</mo>

<msub>
<mrow>
<mi>&delta;</mi>
</mrow>
<mrow>
<mi>y</mi>
</mrow>
</msub>
[/itex]
The non breaking space nbsp is without effect in the following MathML code
(before a </mtext>).
The PNG attachment shows that the space is missing in the output generated by
Mozilla.

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
<mstyle id="x7-6003r18" class="label"/>
<mi>L</mi>
<mi>u</mi>
<mo class="MathClass-rel">=</mo>
<mi>f</mi>
<mtext>&nbsp;in&nbsp;</mtext>
<mi>&Omega;</mi>
[/itex]
On Solaris 10, with either the Sun supplied Mozilla 1.7 or contributied
Firefox 1.04 with xft, in the MathML torture test, each Roman character is
replaces with a corresponding Greek character, e.g., a, b, d, become the
alpha,beta, delta characters. This is similar, but not the same as comment 84.

Mathematical symbols, e.g. <, >, brackets, etc are displayed correctly (expect
for test 28). If the MathML fonts are not configured, the same behavior occurs
(but of course the rendering has many more defects.
Re: Comment #86
&nbsp; has been fixed in bug 297464.
Re: Comment #78
Gecko 1.8-based browsers have significant inter-space improvements via bug 306543.
Re: Comment #88
I meant bug 247151.

Re: Comment #75
Gaps in stretchy characters have been fixed in bug 307157 and bug 311046.
The problems with 2061 (ApplyFunction) and 2062 (Invisible Times) were also fixed in bug 306543.

All these fixes will be in Gecko 1.8-based browsers such as Firefox 1.5.

Re: Comment #80
Both &Vert; and &DoubleVerticalBar; now stretch - fixed in bug 314459
Thanks.  The fix the bug 314459 improves the appearance of a number of my documents.
As per comment 75 on this list I get THSP for &thinspace; at the moment in items 17 and 22 of http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml, but I am using a standard 1.5 build on SuSE 9.2 Linux.  I have followed the font installs as directed on http://www.mozilla.org/projects/mathml/fonts/

Also is there a bug in the TeX item 22 of http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
(http://www.mozilla.org/projects/mathml/screenshots/ex52.gif) ?

The MathML renders it well with a nice script 'l' but the TeX looks like it's using a '1' whereas the 'l' makes much more sense.
Mozilla 1.5 on Win32 and debian

In the integrands, the <mi>xx</mi> terms are rendered using an upright font.  Replacing, e.g., <mi>dt</mi> with <mrow><mi>d</mi><mi>t</mi></mrow> better matches the TeX display.
re: Comment #93 and Comment #94

As you guessed, these are poor markups (discrepancies in the authoring side), as opposed to being bugs in the MathML renderer itself. Per the spec, <mi> is rendered in italics if its textual content consists of a _single_ character, otherwise it is rendered upright, unless overriden by a style instruction.
Firefox 1.5.0.1 on Gentoo Linux; X.org X11 6.8.2; KDE 3.5.1

font.mathfont-family = CMSY10, CMEX10, Mathematica1, Mathematica2, Mathematica4

Output from fc-list includes but is not limited to:
cmsy10:style=Regular
cmex10:style=Regular
Mathematica1:style=Regular
Mathematica2:style=Regular
Mathematica4:style=Regular

These files do exist:
/usr/share/fonts/texcm-ttf/cmsy10.ttf
/usr/share/fonts/texcm-ttf/cmex10.ttf
/usr/share/fonts/mathematica-fonts/Mathematica1.ttf
/usr/share/fonts/mathematica-fonts/Mathematica2.ttf
/usr/share/fonts/mathematica-fonts/Mathematica4.ttf
(In reply to comment #96)
> Created an attachment (id=213905) 
> Severely broken text height calculations
>
> Firefox 1.5.0.1 on Gentoo Linux; X.org X11 6.8.2; KDE 3.5.1

Similar problems on Debian Linux:
Firefox:  Debian/1.5.dfsg+1.5.0.1-3,
X.org X11: 6.9.0dfsg.1-4
KDE 3.5.1

but looks OK on Windows XP (Firefox 1.5.0.1)

The attached picture shows absolute value and determinant (from the MathML Torture Test) rendering incorrectly when I install cmex10.ttf, cmmi10.ttf, cmr10.ttf, and cmsy10.ttf

Alternatively, I can NOT install these four fonts, in which case the absolute value renders well, but the minus sign does not appear.

Changing user.js does not seem to matter.

I am running Camino and Firefox (both had the same results) in OSX.4.7
re:  Comment #98

This pref should resolve the problem:
user_pref("font.mathfont-family", "Math1, Math2, Math4");

You can set the pref with about:config. Once there, just popup the contextmenu and create a new pref entry with name: font.mathfont-family (no quotes) and value:
Math1, Math2, Math4
Unfortunately, I had already added
user_pref("font.mathfont-family", "Math1, Math2, Math4");
And, like I said, turning off the computer-modern fonts solves the absolute value problem, but creates the famous no minus sign problem.

Of course, I did the following (which may be wrong):
user_pref("font.mathfont-family.\u2212.base", "Times");

Both Camino and Firefox change \u2212 to some garble when I check the pref file again (or look it up in about:config). They persist in not rendering the - sign

I also tried:
user_pref("font.mathfont-family.\u02212.base", "Times");
and I also tried changing "Times" to several other options.
> Of course, I did the following (which may be wrong):
>        user_pref("font.mathfont-family.\u2212.base", "Times");

user_pref("font.mathfont-family.\\u2212.base", "Times");
Adding the extra slash in the user pref DID solve the problem. However, the following may be a more robust multi-purpose solution for all users, best I can tell:
user_pref("font.mathfont-family.\\u2212.base",
"Symbol, Courier New, Courier, Times");

Can this line be made a standard preference in all installs/updates until
the Stix fonts render all of this bogus anyway?

I chose the order above due to wanting a solution that prioritizes:
1. a WIDE minus sign. (Times makes a yucky one)
2. Symbol font (apparently Mozilla doesn't believe that the
Symbol font DOES HAVE the minus sign. BIZARRE!)

What do you think?

Thanks for your help so far, by the way. You are very dedicated to making
MathML work for the average user. I am not a programmer, but I am an above average user, and I think average users would find these little things mind-boggline and have no recourse.
Re: Comment #90

> Gaps in stretchy characters have been fixed in bug 307157 and bug 311046.
> The problems with 2061 (ApplyFunction) and 2062 (Invisible Times) were also
> fixed in bug 306543.
>
> All these fixes will be in Gecko 1.8-based browsers such as Firefox 1.5.

I had to temporarily undo this on the 1.8 branch because it caused an obscure, yet serious bug on Linux, bug 321994 - "Firefox doesn't display pages containing MathML", which is still under investigation.
Re: Comment #102

Filed bug 354785 to consider it.
this is a screen shot of the roots being rendered incorrectly on firefox 2.0 running winxp sp2.  the text of the roots drop to the below the roots and the horizontal lines are replaced by black boxes.
I'm stumped.  I cannot find any way to get Firefox to load the Symbol font, despite having tried the advice in #90 of bug 128153 (adding aliasing to .fonts.conf).  fc-match --verbose Symbol finds the URW Symbol font, and it is accessed by Mozilla (ls -lu), but I still get the MathML error message (Symbol font not found), and my square roots are not rendered, summation signs and overbraces etc are rendered incorrectly too.

Any suggestions what I could try next?  Using version 2.0.0.1 on Debian....

Thanks!
Have you tried putting the files in ~/.fonts?
Experiencing same version of problem as Attachment 246031 [details].  I see that it appears to be a very recalcitrant bug.
Firefox 2.0.0.13, Macintosh, similar problem to #105 above.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
I just gave http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml a test in my usual (seamonkey) profile and a couple of different ff profiles.  All on 32-bit Linux.

My seamonkey profile uses just my fonts; everything was OK there.

But all of the ff profiles — including a new one I created just for a test, which had everything left at default — all of the letters were rendered as Greek rather than Latin.  Otherwise they were OK.

I have all of the mathml fonts installed; both the old dist and the Styx fonts.
looking at http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml
with both 20080504 builds for windows and OS X, the sigma and integral signs are too small in tests 10, 12, 16, and 17.  On test 23 the right hand bracket is too close (see the j in the lower right hand side).

The MathML torture page at:
http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml

Needs to update the DTD.

The DTD it is using now:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd"

was recommended in the old:

Mathematical Markup Language (MathML) Version 2.0
W3C Recommendation 21 February 2001
Section: A.2 MathML as a DTD Module

Mathematical Markup Language (MathML) Version 2.0 (Second Edition)
W3C Recommendation 21 October 2003
Section: A.2.3 MathML as a DTD Module

which recommends:

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
"http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd"

Note that the location of the file xhtml-math11-f.dtd is in a new location.

This is:
Bug 448509 -  Make http://www.mozilla.org/projects/mathml/demo/texvsmml.xhtml CSS validate
QA Contact: ian → mathml
Assignee: rbs → nobody
For test #10, those two lines under the summation symbol are achieved using a fraction.  But IMO, a natural (or even a correct) way is to use a matrix (table).  The "torture" isn't severe enough :)

Really, to be honest to Mozilla itself, a matrix should be used.
(In reply to comment #111)
The bugs about the size of sums/integrals as well as the DTD are now fixed. I suppose the bug with the "j" in mtable is the same as bug 415413 (attachment 306114 [details]).

I agree that a mtable should be used. The spec says "The mfrac element is used for fractions. It can also be used to mark up fraction-like objects such as binomial coefficients and Legendre symbols."

---

I attach a patch fixing some errors in the MathML markup:
- Test 14: use &#x3C6; instead of &phiv; (which is really supposed to map to &#x3D5;)
- Test 17: the D in subscript ("domain" of integration) should correspond to the set of the two integrals, not only a single one. I've also replaced these integrals by a "double" integral.
- Test 16, 17: I've splitted the "dx", "dy", "dt" into two <mi/>'s (differential and variable). However, I've keeped the "d" instead of a "double-struck d" as it has been discussed elsewhere.
Firefox 4 in 2011 MathML issues.

Tests 19 through 22 do not render the MathML properly in firefox4b11pre (2011-01-29 build)

http://is.gd/8KKDeL

Debian GNU/Linux 6.0 64 bit
(In reply to comment #116)
> Firefox 4 in 2011 MathML issues.
>
> Tests 19 through 22 do not render the MathML properly in firefox4b11pre
> (2011-01-29 build)
>
> http://is.gd/8KKDeL
>
> Debian GNU/Linux 6.0 64 bit

Please refer to this webpage for instructions on what fonts need to be installed for MathML to work properly with Firefox 4 beta releases.

https://developer.mozilla.org/en/Mozilla_MathML_Project/Fonts
(In reply to comment #117)
> (In reply to comment #116)
> > Firefox 4 in 2011 MathML issues - Debian GNU/Linux 6.0 64 bit

Thanks Bill, fixed my problem and inspired a post:

http://gnubyexample.blogspot.com/2011/01/firefox4-and-mathml-firefox-needs-font.html
Shortened: http://goo.gl/VtUi4

For Debian based distributions everything should already be prepackaged and ready to go, as shown in my article.
Attachment #500672 - Flags: review?(karlt)
Comment on attachment 500672 [details] [diff] [review]
Fixes some errors

I tend to think of the differential d as an operator rather than an identifier.

There is some support for that
http://opus4.kobv.de/opus4-zib/files/797/ZR-04-22.pdf
http://www-sop.inria.fr/apics/tralics/doc-d.html#cmd-DifferentialD
http://markmail.org/message/glymqm7rjb5gyk5p#query:+page:1+mid:esv6srqrq5dyq74x+state:results

But David Carlisle uses the identifier:
http://markmail.org/message/glymqm7rjb5gyk5p#query:+page:1+mid:wtqiggvnsybiphkp+state:results

so I don't mind.
Attachment #500672 - Flags: review?(karlt) → review+
Keywords: checkin-needed
In reference to comment #119

differentiable d is short for differentiable operator.
See
http://en.wikipedia.org/wiki/Differential_operator

it is most definitely an operator.
Whiteboard: [please push attachment 500672] → [please ci attachment 500672 to svn]
Comment on attachment 500672 [details] [diff] [review]
Fixes some errors

http://viewvc.svn.mozilla.org/vc?view=revision&revision=92374
Attachment #500672 - Flags: checkin+
I switched the differential d to operator mo instead of identifier mi.

http://viewvc.svn.mozilla.org/vc?view=revision&revision=92375

I choose mathvariant="italic" to match the LaTeX it is compared with even though some authors use an upright d.
http://en.wikipedia.org/wiki/Integral#Terminology_and_notation
http://en.wikipedia.org/wiki/Variable_of_integration

I'll close this bug as there is too much here to work out what has been fixed and what hasn't.  New bugs can be opened for remaining issues.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Keywords: checkin-needed
Whiteboard: [please ci attachment 500672 to svn]
(In reply to comment #122)
> I switched the differential d to operator mo instead of identifier mi.
>
> http://viewvc.svn.mozilla.org/vc?view=revision&revision=92375
>
> I choose mathvariant="italic" to match the LaTeX it is compared with even
> though some authors use an upright d.

In that case, I think we should also set the space around the operator, otherwise it will be thickmathspace when bug 662756 is fixed.

>
> I'll close this bug as there is too much here to work out what has been
> fixed and what hasn't.  New bugs can be opened for remaining issues.

This bug is still referred on the MathML Torture page. We should update the link "report rendering errors on the demos.", for example to allow users to open a new bug in the MathML component.
(In reply to comment #123)
> In that case, I think we should also set the space around the operator,
> otherwise it will be thickmathspace when bug 662756 is fixed.

I think it's worth setting the default spacing for operator "d" (and its variant characters, I guess) in the operator dictionary.

> This bug is still referred on the MathML Torture page. We should update the
> link "report rendering errors on the demos.", for example to allow users to
> open a new bug in the MathML component.

Oh.  Yes, sounds good.
Assignee: nobody → fred.wang
You need to log in before you can comment on or make changes to this bug.