1994172 - Enable mathml.rtl_operator_mirroring.enabled by default

Status: RESOLVED FIXED

(Core :: MathML, task)

Description

[eri]

Enable the preference mathml.rtl_operator_mirroring.enabled by default (previously nightly only).

Original bug: https://bugzilla.mozilla.org/show_bug.cgi?id=945183

Comment 1

[eri]

Attachment: Bug 1994172 - Enable mathml.rtl_operator_mirroring.enabled by default r?fredw

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/56a8d5300646
https://hg.mozilla.org/integration/autoland/rev/bbed254074a9
Enable mathml.rtl_operator_mirroring.enabled by default r=fredw

Comment 3

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/bbed254074a9

Comment 4

[Frédéric Wang Nélar]

I think we can update https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/146 to mention this.

Intent to ship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/xAISbH3xg1g/m/rFZ_AhWABgAJ?utm_medium=email&utm_source=footer

Comment 5

[Hamish Willee]

FF146 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/41878

I'd love to mention this in the release note and also browser compatibility, but I'm not sure I understand it :-(.
I have read https://people.igalia.com/fwang/mathml-operator-mirroring-explainer.html and https://cr-status.appspot.com/feature/6317308531965952

1. What MathML elements are are affected? This essentially tells me where I need to add a compatibility subfeature. I think
   • the <mo> element for operators that are mirrorable (i.e. containing Unicode characters with Bidi_Mirrored=Yes).
   • Implicit fences (from <mfenced> or inferred by <mrow>)
   • What else? Square root discussed in your examples so is <msqrt> affected? It looks like it is not in the example in https://developer.mozilla.org/en-US/docs/Web/MathML/Reference/Global_attributes/dir
2. Would you like to propose a release note? I can do so for your comment if you prefer.
3. Is there anything that needs to be said in the body of MDN, and if so where? I was thinking that if needed maybe slightly expand the example in https://developer.mozilla.org/en-US/docs/Web/MathML/Reference/Global_attributes/dir

Broadly my understanding of this change is that previously mirroring didn't work and now it does :-).
The explainer says:

Currently for <mo> element is made of a single character c, steps 2 and 3 of layout of operators determine the glyph corresponding to a given character c, and uses that glyph as an input to the MathVariant tables in order to obtain a larger glyph or a glyph assembly. The same is done for the radical symbol of the <msqrt> and <mroot> elements, using character U+221A SQUARE ROOT.

The proposal is simply to amend these steps, so that the input glyph is instead obtain by one of the HTML RTL mirroring techniques (Character-level via Unicode or Glyph-level mirroring) from the character c.

So what I think you're saying is that you used to get the glyph from the MathVariant tables. Now you get them using character level unicode or glyp-level mirroring. I don't get why that matters, but perhaps if you propose a release note it will.

Have tagged both Fred and Eri - sorry if that counts as spam.

Comment 6

[Frédéric Wang Nélar]

(In reply to Hamish Willee from comment #5)

FF146 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/41878

I'd love to mention this in the release note and also browser compatibility, but I'm not sure I understand it :-(.
I have read https://people.igalia.com/fwang/mathml-operator-mirroring-explainer.html and https://cr-status.appspot.com/feature/6317308531965952

1. What MathML elements are are affected? This essentially tells me where I need to add a compatibility subfeature. I think
   • the <mo> element for operators that are mirrorable (i.e. containing Unicode characters with Bidi_Mirrored=Yes).
   • Implicit fences (from <mfenced> or inferred by <mrow>)
   • What else? Square root discussed in your examples so is <msqrt> affected? It looks like it is not in the example in https://developer.mozilla.org/en-US/docs/Web/MathML/Reference/Global_attributes/dir
2. Would you like to propose a release note? I can do so for your comment if you prefer.
3. Is there anything that needs to be said in the body of MDN, and if so where? I was thinking that if needed maybe slightly expand the example in https://developer.mozilla.org/en-US/docs/Web/MathML/Reference/Global_attributes/dir

Probably, we don't need to enter into the technical details. But basically, mirroring of text has always worked for "normal" text (in HTML or most MathML token elements) but didn't work well for operators requiring special stretching/largeop mode (essentially mo and msqrt/mroot elements... we can probably forget about mfenced given its implementation/standardization status).

The meaning of "didn't work" really depends on the browser. For Chromium this is clear: it didn't implement mirroring at all since it was strictly following MathML Core, which didn't previously describe the mirorring steps. Firefox and WebKit had some partial support with some bugs (in particular they didn't use glyph-level mirroring but were only using vertical reflection symmetry instead, which cannot work for things like clockwise contour integral without changing the semantic).

I guess it would be nice to expand the dir article to include the example from https://groups.google.com/a/chromium.org/g/blink-dev/c/IpmWeJSPR0g/m/usfX0V9hAQAJ ; one very important point is that for glyph-level mirroring to properly work, one requires a font with the rtlm font feature (note that some demos may still work in Firefox/WebKit without such font, because of legacy work around). Maybe this should be mentioned on the dir attribute, or on https://developer.mozilla.org/en-US/docs/Web/MathML/Guides/Authoring#mathematical_fonts. The only font I know that has both an OpenType MATH table and rtlm font feature is XITS.

Broadly my understanding of this change is that previously mirroring didn't work and now it does :-).
The explainer says:

Currently for <mo> element is made of a single character c, steps 2 and 3 of layout of operators determine the glyph corresponding to a given character c, and uses that glyph as an input to the MathVariant tables in order to obtain a larger glyph or a glyph assembly. The same is done for the radical symbol of the <msqrt> and <mroot> elements, using character U+221A SQUARE ROOT.

The proposal is simply to amend these steps, so that the input glyph is instead obtain by one of the HTML RTL mirroring techniques (Character-level via Unicode or Glyph-level mirroring) from the character c.

So what I think you're saying is that you used to get the glyph from the MathVariant tables. Now you get them using character level unicode or glyp-level mirroring. I don't get why that matters, but perhaps if you propose a release note it will.

For operator stretching/largeop, we get the base glyph from the unicode codepoint of the operator, use it as a key in the MathVariant table to get either a larger glyph or a glyph assembly. This is still the case after that change, the only difference is that we may add glyph-level mirroring or character-level mirroring to determining the base glyph.

So maybe the summary is "In the past mirroring worked for normal text and stretching/largeop worked for math operators ; now the these two features properly work when used in combination".