Chrome can't display \vec in Windows XP and Vista

[dpvc]

Chrome displays a "missing character" box for the \vec arrow (and several other characters) in the web fonts in Windows XP and Windows Vista (but not Windows 7).

[dpvc]

It turns out that Chrome on Windows XP can't access four accents from the web fonts used by MathJax. These are the combining arrow above (U+20D7), the combining dot above (U+0307), combining double acute accent (U+030B), and the combining long solidus overlay (U+0338). The other browsers on XP (or any other platform) have no trouble with these, so I don't think it is a problem with the font. Historically, Chrome on XP has had some problems with the web fonts with a few characters being inaccessible (a "T" in one font, a "d" and ">" in another, and several others). I'm not sure what version of Chrome first had problems with the vector arrow (I know for a fact that it worked at one time, but am not sure the version at this point).

[Herst]

Could this have to do with the version of the Uniscribe library? (Though I am not sure whether Chrome uses it, but I do know that older versions of Firefox did).
So if I am correct then you might get reports from people on these platforms who don't have this issue because an application might have installed a newer version of the library for them.

[fred-wang]

Maybe that's also related to the use of a combining characters (perhaps Chrome expects another character to combine with or something), although you said that happened with non-combining characters in the past.

#119

[dpvc]

Issue #202 is a duplicate of this one.

[dpvc]

The issue239 branch of my fork of MathJax works around the characters that Chrome can't display. The dot, double acute accent, and solidus overlay were relatively easy, as other characters in the font could be used for these. The vector arrow was harder as I had to use the regular right arrow, which is too big. But at least it gets the point across.

[fred-wang]

Marking this "Do not automated test" (as the duplicate bug) and I trust you with the manual testing of this. IIUC, the commit only remaps some characters (I can't really see the diff with the new github interface) so I think it is safe to take this change.

=> Do Not write automated test, ready for release

[dpvc]

I really wish they would fix that issue with the diffs not showing. I may have to go to a two-commit system that make the unpacked changes separately from the packed ones to avoid the problem.

[fred-wang]

I think we should really only track the changes of the unpacked version (at least for the development branches). That avoids to have to pack/recombine MathJax after each commit. That also helps to merge different branches without getting conflicts.

Personally, I can just modify the script that generates the branches at http://devel.mathjax.org/mathjax/, so that it automatically combine/pack the branches. One can also test with the unpacked/ version. I don't know what is the best for you.

[dpvc]

The reason I have been doing the packing and combining is that others might check out a branch and I wanted the packed copy (the default) to reflect the changes in the branch, so all the files in the branch would be consistent. (This also helps me as I check out different branches as I work).

I think it is best to do the testing from a packed copy, since that is the usual use-case and there are some timing differences between the two (when combined configuration files are used). Since I test mostly with unpacked, it is good to have you testing with packed versions. It may just be best to do two commits.

[fred-wang]

I've reported this bug upstream (that would be great if someone could check whether the bug is still there):

https://bugs.webkit.org/show_bug.cgi?id=112366