413115 - infinity (∞) and other symbols are rendered as hex boxes in mathml expressions on Windows with STIX fonts.

Status: RESOLVED FIXED

(Core :: MathML, defect, P2)

Description

[SamyDagan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011815 Minefield/3.0b3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011815 Minefield/3.0b3pre

The infinity symbol of a mathml expression is not properly displayed by Minefield on Windows XP with Stix fonts, (but is rendered correctly On Mac OSx).

Reproducible: Always

Steps to Reproduce:
1.Open a xhtml file mathml expression that includes the infinity symbol by Minefield on windows XP machine.
2.The symbol is not properly displayed.
3.
Actual Results:  
Instread of the infinity symbol a square appears with its hexadecimal code (221E).

Expected Results:  
The infinity symbol to be displayed.

The bug appears on wndows XP, but does not appear on Mac OSx.

Comment 1

[SamyDagan]

Attachment: Example of a mathml expression including the infinity symbol.

Comment 2

[Karl Tomlinson (:karlt)]

There are a few issues here:

1) The default value of the mathvariant attribute on <mi> elements with a
   single character is italic, but this should only cause alphanumeric symbols
   to take italic forms.

   http://www.w3.org/TR/2007/WD-MathML3-20071214/chapter3.html#presm.commatt:

   "By design, the only cases that have an unambiguous interpretation are
   exactly the ones that correspond to SMP Math Alphanumeric Symbol
   characters, which are enumerated in Section 6.5 Mathematical Alphanumeric
   Symbols. The mathvariant values "initial", "tailed", "looped" and
   "stretched" are expected to apply only to Arabic characters. In all other
   cases, it is suggested that renderers ignore the value of the mathvariant
   attribute if it is present."

2) The Italic subfamily of STIXGeneral does not support the infinity
   character.  The Roman subfamily does, but bug 382542 is preventing the
   Roman family from being used for fallback.

3) <mi mathvariant="normal">&#x221E;</mi> shows a glyph for the infinity
   symbol but it is from the wrong font (serif).

Comment 3

[Karl Tomlinson (:karlt)]

Attachment: let mathvariant="normal" inherit the document fonts [checked-in]

(Adding an explicit mathvariant="normal" to an <mi> that has default mathvariant="normal" should not change the font.)

Comment 4

[Karl Tomlinson (:karlt)]

Comment on attachment 298152 [details] [diff] [review]
let mathvariant="normal" inherit the document fonts [checked-in]

This would fix issue 3 and its a low risk change.

Comment 5

[Karl Tomlinson (:karlt)]

Comment on attachment 298152 [details] [diff] [review]
let mathvariant="normal" inherit the document fonts [checked-in]

checked in with a reftest for issue 3.

Comment 6

[Karl Tomlinson (:karlt)]

Either issue 1 or issue 2 (or both) needs to be fixed by FF3.
Depending on how bug 382542 is resolved (for issue 2) we may still need to resolve issue 1.

Comment 7

[Damon Sicore (:damons)]

OK.  +'ing as well, math needs infinity.

Comment 8

[Karl Tomlinson (:karlt)]

Attachment: fix for issue 1 in comment 2

Only change the style of default mathvariant <mi> elements to italic when
there is a corresponding italic Mathematical Alphanumeric Symbol.

Accept non-BMP characters in nsMathMLOperator::LookupInvariantChar.
Update the mathvariant entries in mathfont.properties from PUA characters to
their Plane 1 Unicode assignments.  (Remainder of bug 289938)

The mathvariant strings were generated by saving
http://www.w3.org/TR/2003/REC-MathML2-20031021/italic.html and others as text,
editting sans-serif-bold-italic.txt to remove line wrapping, and running
this command (with the line-wrapping removed):

for file in *.txt; sed -e '0,/^Unicode/d' -e '/^$/,$d' $file | perl -MEncode -wne '$SIG{__WARN__}=sub{warn "$_ ",@_;};($v,$k) = map hex, (split)[0,1]; $k < 0x80 ? print chr $k : printf "\\u%04X", $k; printf "\\u%04x\\u%04x", unpack("n*", encode "utf-16be", chr $v), 0xfffd' > $file:r.string

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 309339 [details] [diff] [review]
fix for issue 1 in comment 2

+    if (!(mContent->HasAttr(kNameSpaceID_None, nsGkAtoms::mathvariant_) ||
+          mContent->HasAttr(kNameSpaceID_None, nsGkAtoms::fontstyle_))) {
+      if (!isSingleCharacter) {
+          fontstyle.AssignLiteral("normal");
+      }
+      else if (length == 1 && // BMP
+               !nsMathMLOperators::
+                TransformVariantChar(data[0], eMATHVARIANT_italic).
+                Equals(data)) {
+       // Transformation exists.  Try to make the BMP character look like the
+       // styled character using the style system until bug 114365 is resolved.
+       fontstyle.AssignLiteral("italic");
+      }
+      // else single character but there is no corresponding Math Alphanumeric
+      // Symbol character: "ignore the value of the [default] mathvariant
+      // attribute".
+    }

Not sure what indenting rules you're using here...

Comment 10

[Karl Tomlinson (:karlt)]

Attachment: fix for issue 1 in comment 2 [checked-in]

(In reply to comment #9)
> Not sure what indenting rules you're using here...

The kind that results when I find tabs in the patch and try to remove them by hand ;)

Added another emacs mode line and updated contributors.

Comment 11

[Karl Tomlinson (:karlt)]

Comment on attachment 309714 [details] [diff] [review]
fix for issue 1 in comment 2 [checked-in]

checked-in with reftest

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1205633391&maxdate=1205633412&who=karlt%2B%25karlt.net
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1205634355&maxdate=1205634427&who=karlt%2B%25karlt.net

Comment 12

[Karl Tomlinson (:karlt)]

There could still be some issues if italic style is explicitly applied (bug   	324857) but the normal cases should be fixed.

Comment 13

[SamyDagan]

I am satisfied. Thanks, Samy

Comment 14

[Karl Tomlinson (:karlt)]

Thanks for checking.

(In reply to comment #12)
> There could still be some issues if italic style is explicitly applied (bug    
> 324857) but the normal cases should be fixed.

In case anyone is seeing issues, I meant bug 382542 (not 324857).