SVG output and vnsub

[pkra]

Using SVG ouptut, Chrome and WebKit 2.8.5 (but not FF) render ⊂⃒ (or ⊂⃒ or ⊂⃒) (which is not covered by our fonts so fallbaks are used) as plain subset.

[pkra]

Stumbling upon this again, I think it might be a case of #474, rather than a browser bug. @dpvc is that correct?

[dpvc]

It now works for me in Firefox, so perhaps it is a moot point. I think 474 is slightly different, in that the combining glyphs actually form a different glyph in the case, while here the combining glyph simply wasn't being shown. Some browsers don't like to draw a combining glyph if there is nothing for it to combine with, and MathJax does include code to work around that, but that is mostly for accents.

Are you still seeing the issue (on current develop branch)?

[pkra]

I think 474 is slightly different, in that the combining glyphs actually form a different glyph in the case, while here the combining glyph simply wasn't being shown.

Thanks for the clarification.

Are you still seeing the issue (on current develop branch)?

I see the both glyphs now on FF and Chrome though WebKit still shows only ⊂ (even in HTML-CSS / CommonHTML which I may not have checked before).

But even on FF and Chrome it looks more like ⊂ | then ⊂⃒ (again, all outputs actually).

[dpvc]

But even on FF and Chrome it looks more like ⊂ | then ⊂⃒

Here's what I see on Mac OS X:

These are for SVG, CommonHTML, and HTML-CSS, all with TeX fonts.

For STIX fonts, I see

in SVG and HTML-CSS (CommonHTML doesn't use STIX fonts yet).

While the TeX font arrangement is not ideal, it is not the separation that you see. Is that the Linux output?

[dpvc]

I have made a U+20D2 branch that handles the U+20D2 character via backspacing and vertical bar instead of the combining character. See what you think of that. The combining characters have always been a pain as they are handled differently by different browsers and OSes. Not sure if it is better to replace them by this kind of spacing hack, or try to find more browser-specific work-arounds.

[pkra]

Thanks, Davide. The changes on your new branch look better.

While looking at them I wondered if we were talking about two different things re #474. I still see what I described with TeX input (e.g., $$⊂⃒$$) but <math display='block'><mi>&vnsub;</mi></math> looked like your screenshots for me too.

Actually, on your branch, even the TeX input looks good on CommonHTML (but not the other outputs), testing Chrome, Web(Kit), Firefox. WebKit still loses the strike-through glyph in SVG no matter the input.

FYI, this bug isn't any kind of priority from my end; I was just going through the browser bug tag. Seems like Webkit is the only browser bug part left.

[dpvc]

Sorry, I didn't realize you were talking about TeX input (the original message didn't specify the input format). You are right, in the TeX setting, since ⊂⃒ is a two-character entity (U+2282 U+20D2), the TeX input jax picks it up as two separate <mo> elements. That does interfere with the rendering. So you are right that this could be viewed as #474 in that combining character might want to be included in the same MathML node as the preceding character.

Technically, one ought not to be using such characters in TeX anyway. One solution would be to use \mmlToken{mo}{⊂⃒} instead, or \def\vnsub{\mmlToken{mo}{⊂⃒}} and then use \nvsub.

[dpvc]

Alternatively, you could use

<script type="text/x-mathjax-config">
MathJax.Hub.Register.StartupHook("TeX Jax Ready",function () {
  MathJax.InputJax.TeX.prefilterHooks.Add(function (data) {
    data.math = data.math.replace(/(.\u20D2)/g,"\\mmlToken{mo}{$1}");
  });
});
</script>

to pre-filter the TeX input to add the \mmlToken macro for you.

[dpvc]

If you want to rename this something like "TeX Input: include postfix combining diacritical marks with preceding character", and remove the browser bug label, I'd be OK with that.

[pkra]

Thanks, Davide. I don't remember if I was thinking of TeX input when I opened this.

If it's ok with you, I'd propose to leave this bug as.

On the one hand, the browser bug in the OP persists on WebKit (even though Blink seems to have fixed it). On the other hand, I think #474 is sufficient for the TeX-input problem.

[dpvc]

the browser bug in the OP persists on WebKit

Do you mean in MathML or TeX? For me in Safari 9.1.1 the MathML version works as expected. The images I gave above were from Safari. It may have been fixed in a recent WebKit, so older WebKit browsers don't yet have the fix?

[pkra]

For me in Safari 9.1.1 the MathML version works as expected.

Interesting. I can confirm that. My other browser is Gnome's Web, using WebKit 2.10.9 which was released 4 days before Safari 9.1. (Then again, IIUC, they are not always comparable.)

Closing this then.