User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3.1) Gecko/20030425 Build Identifier: MathML render on Linux doesn't make any bidi/joining algorithm for arabic/persian texts and show them in Isolated form in LTR mode. Reproducible: Always Steps to Reproduce: 1. Take a look at http://esfahbod.info/proj/web/xml/farsi/math.xms with Mozilla on a Linux OS. Actual Results: it is wrong! in MS Windows, it looks right. You can see correct render with Mozilla 1.3.1 on WinXP in next attachment. Expected Results: It must looks like attachment.

Created attachment 124926 [details] Persian/Arabic text in MathML Screenshot of Persian (farsi) text example in MathML with Mozilla 1.3.1 on MS WinXP.

Confirming.

The MathML spec has no provision for BiDi. I know of a research project that has been investigating BiDi mathematical typesetting. The two approaches currently in use are: either write the formulas from right to left, with mirrored symbols (as it is done in Egypt and Syria), or write the formulas from left to right (as it is done in Morocco and Algeria), which makes translation easier from Latin languages but involves the mixing of directions in the same document. In other words: in Egypt/Syria they do: RTL text + RTL math (with "mirrored" (flipped) symbols) in Morocco/Algeria they do: RTL text + LTR math Mozilla does the latter (the MathML spec is silent on this...), and so it is not a bug. The research group that I mentioned earlier suggested adding a |dir| attribute to the top <math> element so as to pick one approach or the other. But this hasn't caught on. Suggesting to mark this WONTFIX or at least Future.

Created attachment 124985 [details] Wrong Persian/Arabic text in MathML Screenshot of Persian (farsi) text example in MathML with Mozilla 1.2.1 on RedHat Linux 9. View and Bidi/Joining alghorithm of Persian/Arabic texts are defined in Unicode (/reports/tr9, etc). The xml:lang in XML is used for correct view on presentations. as it selects the correct shape for CJK glyphs, it should show Arabic/Hebrew text in right direction (bidi) and glyphs (joining). My example is [ Math LTR + Text RLT ] and as you can see in previous attachment, Mozilla on MS Win has right view. There is no relation between direction of Math writing, and arabic/hebrew texts' bidi/joining.

This is a parallel issue to bug 168455. To fix it we need at minimum to add some MathML frame types to the list of frames that could have text frames as descendants in nsBidiPresUtils.cpp (or as I said in bug 168455 comment 3 find a general solution that doesn't require that hard-coded list).

I am not familiar with what you are saying re: nsBidiPresUtils.cpp. But my understanding of this issue is just that no special (bidi) action is needed in the <math>...</math> environment.

Regarding to MathML's Bidi Layout [BIDLAY] specification, Bidi alghorithm should work on arabic texts on this test page [SAMPLE-1]. I'll attach screenshots. SAMPLE-1:http://bamdad.org/~behnam/persian/mozilla/mathml/sample-mtext-mi-mn.xhtml BIDILAY:http://www.w3.org/TR/MathML2/chapter3.html#presm.bidi

Created attachment 159867 [details] Sample-1 on FireFox 0.9.3 There's no Bidi/Shaping on arabic/persian texts in mathml on firefox.

Created attachment 159868 [details] Sample-1 on FireFox 0.9.3, Fedora Core 2 There's no Bidi/Shaping on arabic/persian texts in mathml on firefox with xft and gtk2 enabled. (fedora core 2 rpms)

Created attachment 159869 [details] Sample-1 on FireFox 0.9.3, Windows XP There's no Bidi on arabic/persian texts in mathml on firefox on windows, but its text render engine does shaping and bidi on words.

Created attachment 161127 [details] Sample-1 on FireFox 0.9.3, CVS 04-10-02, enable-pango Every thing seems like what BIDILAY says about Arabic/Persian texts in mathml, with enable-pango option. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041002 Firefox/0.9.1+

Created attachment 239479 [details] Test case Upload the test case to make up2date screenshots.

Needs reassign?

http://pastebin.mozilla.org/545 is a permanent copy of W3C's MathML spec, section Bidi Layout [BIDLAY].

Now that I've read the relevant parts of the spec, I see that comment 5 is wrong, and we have to do Bidi rather differently here. Calling nsBidiPresUtils::Resolve() as we do in normal HTML frames would be overkill. Taking bug.

MathML 3 introduces mechanisms for controlling the Directionality of layout. See bug 534963

According to comment 4, this bug is only for the section "Bidirectional Layout in Token Elements" that was already in MathML 2 spec. I suggest changing the Summary of this bug, not to confuse with the "Overall Directionality of Mathematics Formulas" (called "RTL math" in comment 3). From what I can currently test with a trunk build and according to comment 11, the move to pango library partially fixed this bug. I noticed that mirroring is not applied to some <mo>'s, more precisely to operators drawn with a nsMathMLChar (a class used for stretching math characters). Does a general mechanism exist in Mozilla to get the mirror of a character (when Unicode marks it as mirrored)? (In reply to comment #15) > Now that I've read the relevant parts of the spec, I see that comment 5 is > wrong, and we have to do Bidi rather differently here. Calling > nsBidiPresUtils::Resolve() as we do in normal HTML frames would be overkill. > Taking bug. Can you check the MathML 3 version and indicate how you think it should be implemented? http://www.w3.org/TR/2009/CR-MathML3-20091215/chapter3.html#presm.bidi.token

(In reply to comment #17) > From what I can currently test with a trunk build and according to comment 11, > the move to pango library partially fixed this bug. I noticed that mirroring is > not applied to some <mo>'s, more precisely to operators drawn with a > nsMathMLChar (a class used for stretching math characters). Does a general > mechanism exist in Mozilla to get the mirror of a character (when Unicode marks > it as mirrored)? Would using nsIRenderingContext::SetRightToLeftText or SetTextRunRTL from nsMathMLChar be suitable? (I don't know whether that would have already been set.) Or adding appropriate Unicode controls in the DrawString() strings may be a option. Really nsMathMLChar should be updated to use gfxFontGroup and gfxTextRun instead of nsIRenderingContext, but I don't know how much work that is.

> Would using nsIRenderingContext::SetRightToLeftText or SetTextRunRTL from > nsMathMLChar be suitable? (I don't know whether that would have already been > set.) Or adding appropriate Unicode controls in the DrawString() strings may > be a option. > SetTextRunRTL seems to work when drawing a single glyph but I was thinking about converting the mData (for example '{' to '}') so that it also works for a stretchy characters built by parts.

The bidi algorithm should apply to token elements. These elements contain only text (we don't support mglyph or malignmark) and apparently bidi already works in that case. Hence, the real problem to solve is nsMathMLChar. I think this class is only used for <mo/>'s with a single character, so the bidi algorithm restricts to "glyph mirroring". I see two cases: 1) In nsMathMLChar::SetData, add a Unicode control to convert some characters to their mirrors counterparts (parenthesis, brackets etc) 2) In nsMathMLChar::PaintForeground, apply negative scale to some characters (Sum, Square, Integrals...). In bug 534963 comment 6, I also suggest to use arabic fonts as Dadzilla does. But one of the author of Dadzilla told me that they created two fonts ACMSY10, ACMEX10 (which simply contain mirrored glyphs of CMSY10, CMEX10) that are used when dir="rtl" (but adding some exceptions for some characters). Consequently, I think it's just better to use negative scale. So case 2 should wait for bug 414277...

Created attachment 423546 [details] [diff] [review] patch (1st version) This patch is based on attachment 423544 [details] [diff] [review]. It adds a new attribute in the Operator Dictionary to indicate whether a character is mirrorable. When drawn in a RTL context, a negative coefficient is applied to mirror them. My previous idea (control in the nsMathMLChar::SetData) does not work, because the RTL context is not known at this time. Hence the control (that simply sets the value of a boolean mMirrored) is rather put in the nsMathMLChar::Stretch.

Created attachment 450849 [details] [diff] [review] Mirroring of operators for arabic math (V2)

Created attachment 465356 [details] [diff] [review] Mirroring of operators for arabic math (V3)

Created attachment 468180 [details] [diff] [review] Mirroring of operators for arabic math (V4)

I'd like to note that simply mirroring mirror-able glyphs is acceptable in all cases, for example mirroring cube root ∛ (U+221B) will mirror the digit as well, and mirroring clockwise contour integral ∲ (U+2232) will make it anticlockwise. It is inevitable to have a font with dedicated mirrored forms. XITS Math font (OpenType MATH-enabled derivative of STIX fonts), have dedicated mirror glyphs (in git master, still does not cover all characters with Unicode BiDi_Mirrored property, but enough for concept testing) and they are mapped using OpenType 'rtlm' feature (Right-to-left mirrored forms). https://github.com/khaledhosny/xits-math http://twitpic.com/5cw8l5

(In reply to comment #25) > I'd like to note that simply mirroring mirror-able glyphs is acceptable in > all cases, for example mirroring cube root ∛ (U+221B) will mirror the digit > as well, and mirroring clockwise contour integral ∲ (U+2232) will make it > anticlockwise. It is inevitable to have a font with dedicated mirrored forms. > > XITS Math font (OpenType MATH-enabled derivative of STIX fonts), have > dedicated mirror glyphs (in git master, still does not cover all characters > with Unicode BiDi_Mirrored property, but enough for concept testing) and > they are mapped using OpenType 'rtlm' feature (Right-to-left mirrored forms). > > https://github.com/khaledhosny/xits-math > http://twitpic.com/5cw8l5 Thank you for this remark. Can you tell me if <mtext style="direction: rtl;">∛</mtext> works with your XITS fonts? If so, we only need to handle the <mo> case. To do that, I think we have to fix bug 663740, on which Daniel Cazacu is working as a summer project. This bug will also be useful to fix bug 407059 and hopefully allow support for more OpenType fonts. I think mirroring glyphs with scale transform will work for the most common characters (integral, sum, parentheses...). Just as the scale transform used to stretch characters, this will be a useful workaround for users that don't have the relevant fonts installed.

(In reply to comment #26) > Thank you for this remark. Can you tell me if > > <mtext style="direction: rtl;">∛</mtext> Something like that works: <mtext style="direction: rtl; font-family: 'XITS Math'">∛ب</mtext> Without the Arabic letter after the root it doesn't, but the same is true for text outside <math> so I guess it is a general bug on how the directionality of the text run is determined. > works with your XITS fonts? If so, we only need to handle the <mo> case. To > do that, I think we have to fix bug 663740, on which Daniel Cazacu is > working as a summer project. This bug will also be useful to fix bug 407059 > and hopefully allow support for more OpenType fonts. That would indeed allow much wider variety of math fonts (there is currently 5 OpenType math fonts publicly available and more in the pipelines, both libre and proprietary) > I think mirroring glyphs with scale transform will work for the most common > characters (integral, sum, parentheses...). Just as the scale transform used > to stretch characters, this will be a useful workaround for users that don't > have the relevant fonts installed. That would be a good compromise, though with the advance of web fonts user installed fonts are becoming less of an issue.

> Something like that works: > > <mtext style="direction: rtl; font-family: 'XITS Math'">∛ب</mtext> > > Without the Arabic letter after the root it doesn't, but the same is true > for text outside <math> so I guess it is a general bug on how the > directionality of the text run is determined. OK, thanks for the info. If that's not what the specs say, can you please open a separate bug stating that <span style="direction: rtl; font-family: 'XITS Math'">∛ب</span> works but not <span style="direction: rtl; font-family: 'XITS Math'">∛</span>?

Created attachment 560432 [details] [diff] [review] Mirroring of operators for arabic math - part 1 (V5)

Created attachment 560433 [details] [diff] [review] Mirroring of operators for arabic math - part 2 (V5)

Can you please post a screenshot of how this would look on the screen?

Testcase from the MathML testsuite: http://www.w3.org/Math/testsuite/build/main/Topics/BiDi/Complex/Maghreb1-simple.xhtml

Created attachment 561260 [details] screenshot of Maghreb1 with patches from this bug and mathml-dir applied.

Comment on attachment 561260 [details] screenshot of Maghreb1 with patches from this bug and mathml-dir applied. Are these patches making this change to all languages using the Arabic script, or just the Arabic language? Doing this doesn't make a lot of sense in Persian, for example.

I'm not sure what you mean but I'm trying to implement what is described in the following W3C documents, which should take into account all the local particularities. http://www.w3.org/TR/arabic-math/ http://www.w3.org/TR/MathML3/chapter3.html#presm.bidi Bidi/Joining algorithm should already be implemented inside token MathML elements (<mtext>, <mi>...), except for mathematical operators (<mo>). The patches from this bug only adds the possibility to mirror some of these mathematical operators (attachment 560433 [details] [diff] [review]). The overall directionality of formulas is implemented in bug 534963.

If I'm reading the first link correctly, the rendering of attachment 561260 [details] is Maghreb Style <http://www.w3.org/TR/arabic-math/#Maghreb>, which is supposed to be unspecified in MathML. The mirroring should not happen in other styles, and it should definitely not happen if you set the direction of the mathml tree to rtl. Unless I'm misinterpreting the spec (note that I don't know a lot about MathML in general).

(In reply to Ehsan Akhgari [:ehsan] from comment #36) > If I'm reading the first link correctly, the rendering of attachment 561260 [details] > [details] is Maghreb Style <http://www.w3.org/TR/arabic-math/#Maghreb>, > which is supposed to be unspecified in MathML. > The first link is an old "W3C Note" and so should not be considered normative. I gave it just to have examples of different styles. A concrete example of markup for the Maghreb Style was written by MathML folks after this note, using the MathML3 syntax (see comment 32). > The mirroring should not happen in other styles, and it should definitely > not happen if you set the direction of the mathml tree to rtl. Unless I'm > misinterpreting the spec (note that I don't know a lot about MathML in > general). The "style" depends on how the author use the dir attributes. If you put such an attribute dir=rtl on the mathml root, then the overall directionality is RTL and per the MathML REC, this direction is used by default for the token elements: "The base, or initial, direction is given by the overall directionality described above"

> Are these patches making this change to all languages using the Arabic > script, or just the Arabic language? Doing this doesn't make a lot of sense > in Persian, for example. For the Persian style, the MathML "dir" attribute would typically not be used (as in attachment 239479 [details]). The overall directionality of the formula is LTR and so is the initial directionality inside token elements. But when Persian text is used in these token elements, the bidi algorithm applies and the directionality becomes RTL.

(Note that I'm mostly talking about the mirroring of things such as the summation and integration symbols...) There is also the Moroccan style: <http://www.w3.org/Math/testsuite/build/mathml3/Topics/BiDi/Complex/Moroccan1-full.xhtml>, which is what makes sense for the Persian language. Will we support both styles? If yes, how would the authors request one or the other?

(In reply to Ehsan Akhgari [:ehsan] from comment #39) > (Note that I'm mostly talking about the mirroring of things such as the > summation and integration symbols...) > > There is also the Moroccan style: > <http://www.w3.org/Math/testsuite/build/mathml3/Topics/BiDi/Complex/ > Moroccan1-full.xhtml>, which is what makes sense for the Persian language. > Will we support both styles? If yes, how would the authors request one or > the other? Yes, we already support the Moroccan/Persian style, which is the default. The patches add support for the "dir" attribute on the MathML element. You'll just have to set this attribute to rtl to enable the Maghreb style.

Created attachment 561413 [details] screenshot of the testcase

Great, thanks for the clarification!

(In reply to Frédéric Wang (:fred) from comment #29) > Created attachment 560432 [details] [diff] [review] [diff] [details] [review] > Mirroring of operators for arabic math - part 1 (V5) This patch need to be updated due to the elimination of the PRBool data type.

Created attachment 566760 [details] [diff] [review] Mirroring of operators for arabic math - part 1 (V6)

Comment on attachment 560433 [details] [diff] [review] Mirroring of operators for arabic math - part 2 (V5) >+operator.\u2231.prefix = lspace:0 rspace:1 largeop symmetric direction:vertical integral mirrorable # clockwise integral >+operator.\u2232.prefix = lspace:0 rspace:1 largeop symmetric direction:vertical integral mirrorable # ∲ >+operator.\u2233.prefix = lspace:0 rspace:1 largeop symmetric direction:vertical integral mirrorable # ∳ >+operator.\u2A11.prefix = lspace:1 rspace:2 largeop movablelimits symmetric direction:vertical integral mirrorable # anticlockwise integration I see these listed in the comments of BidiMirroring.txt, but I'm not sure that means that a reflection produces the correct glyph. Wouldn't mirroring change the meaning of the symbol, and so it would be better not to mirror these? >+operator.\u2A17.prefix = lspace:1 rspace:2 largeop symmetric direction:vertical integral mirrorable # integral with leftwards arrow with hook I don't know what to think about this one.

Looks like we need the patches in bug 534963 before these.

OK, maybe it's best not to mirror those glyphs if we are not sure.

https://raw.github.com/fred-wang/MozillaCentralPatches/master/mirror-op-1.diff https://raw.github.com/fred-wang/MozillaCentralPatches/master/mirror-op-2.diff

(In reply to Frédéric Wang from comment #48) > https://raw.github.com/fred-wang/MozillaCentralPatches/master/mirror-op-1. > diff > https://raw.github.com/fred-wang/MozillaCentralPatches/master/mirror-op-2. > diff I made the attached patches obsolete. The last versions are in my patch queues.

Created attachment 582652 [details] [diff] [review] Mirroring of operators for arabic math - part 1 (V7)

Created attachment 582653 [details] [diff] [review] Mirroring of operators for arabic math - part 2 (V6)

Created attachment 582696 [details] [diff] [review] reftest I've just launched the test: https://tbpl.mozilla.org/?tree=Try&rev=7e6857fd3f8f (I'm not sure using -moz-transform is a good idea)

Comment on attachment 582652 [details] [diff] [review] Mirroring of operators for arabic math - part 1 (V7) >+ if (aRTL && nsMathMLOperators::IsMirrorableOperator(mData)) { >+ mMirrored = true; >+ } I guess mMirrored will never need to change from true to false in practice, but the nsMathMLChar API allows that change to happen (through SetData or aRTL), so this should be changed to mMirrored = aRTL && nsMathMLOperators::IsMirrorableOperator(mData) > ReflowChar(aPresContext, *aReflowState.rendContext, mOpenChar, > NS_MATHML_OPERATOR_FORM_PREFIX, font->mScriptLevel, >- axisHeight, leading, em, containerSize, ascent, descent); >+ axisHeight, leading, em, containerSize, ascent, descent, >+ NS_MATHML_IS_RTL(mPresentationData.flags)); > ///////////////// > // separators ... > for (i = 0; i < mSeparatorsCount; i++) { > ReflowChar(aPresContext, *aReflowState.rendContext, &mSeparatorsChar[i], > NS_MATHML_OPERATOR_FORM_INFIX, font->mScriptLevel, >- axisHeight, leading, em, containerSize, ascent, descent); >+ axisHeight, leading, em, containerSize, ascent, descent, >+ NS_MATHML_IS_RTL(mPresentationData.flags)); > } > ///////////////// > // closing fence ... > ReflowChar(aPresContext, *aReflowState.rendContext, mCloseChar, > NS_MATHML_OPERATOR_FORM_POSTFIX, font->mScriptLevel, >- axisHeight, leading, em, containerSize, ascent, descent); >+ axisHeight, leading, em, containerSize, ascent, descent, >+ NS_MATHML_IS_RTL(mPresentationData.flags)); A local variable (e.g. bool isRTL) could be used to save NS_MATHML_IS_RTL(mPresentationData.flags) so that it is not repeated. > // let the MathMLChar stretch itself... > nsresult res = mMathMLChar.Stretch(PresContext(), aRenderingContext, >- aStretchDirection, container, charSize, stretchHint); >+ aStretchDirection, container, charSize, stretchHint, NS_MATHML_IS_RTL(mPresentationData.flags)); Try to keep the code within 80 columns.

Created attachment 582753 [details] [diff] [review] Mirroring of operators for arabic math - part 1 (V8)

(In reply to Frédéric Wang from comment #52) > Created attachment 582696 [details] [diff] [review] > reftest > > I've just launched the test: > > https://tbpl.mozilla.org/?tree=Try&rev=7e6857fd3f8f > > (I'm not sure using -moz-transform is a good idea) So the test seems to be failing for square root and integral. So I've kept -moz-transform for fences and use != tests for the other symbols. New try: https://tbpl.mozilla.org/?tree=Try&rev=516b9b614ed9

Created attachment 582777 [details] [diff] [review] reftests (V2)

Comment on attachment 582777 [details] [diff] [review] reftests (V2) (In reply to Frédéric Wang from comment #55) > So the test seems to be failing for square root and integral. So I've kept > -moz-transform for fences and use != tests for the other symbols. Could be associated with gfx rounding the position of the glyphs. The test passed with DWrite.

Order of patches: https://bugzilla.mozilla.org/attachment.cgi?id=582753 https://bugzilla.mozilla.org/attachment.cgi?id=582653 https://bugzilla.mozilla.org/attachment.cgi?id=582777

Regarding behavior of <math> element with dir="rtl", if we write: <p> <math dir="rtl"><mi>x</mi></math> <math dir="rtl"><mi>y</mi></math> </p> then "yx" is rendered. I don't think it's described in the MathML REC, but I suppose it is what the Bidi algorithm says? Joining algorithm inside a token frame was already implemented, but we don't do it between MathML separate token frames. That seems do be the same as what we do for handwritten mathematics in latin letters (we don't join x and y in the example above). That's what the MathML3 rec says: "Additionally, calligraphic scripts such as Arabic blend, or connect sequences of characters together, changing their appearance. As this can have an significant impact on readability, as well as aesthetics, it is important to apply such shaping if possible. Glyph shaping, like directionality, applies to each token element's contents individually." So we can maybe write an != reftest like this (I hope arabic letters will render correctly in Bugzilla): <math dir="rtl"><mtext>مجهول</mtext></math> (joined) <math dir="rtl"><mtext>م</mtext><mtext>ج</mtext><mtext>ه</mtext><mtext>و</mtext><mtext>ل</mtext></math> (disjoined) The joining algorithm has always worked for me, so I don't know if this test can really the bug, though. For bidi inside token frames, an == reftest like this seems to work fine: <math dir="rtl"><mtext>و</mtext><mtext>ل</mtext></math> <math><mtext>ول</mtext></math>

> (we don't join x and y in the example above). I meant in <math><mi>x</mi><mi>y</mi></math>

(In reply to Frédéric Wang from comment #59) > Regarding behavior of <math> element with dir="rtl", if we write: > > <p> > <math dir="rtl"><mi>x</mi></math> > <math dir="rtl"><mi>y</mi></math> > </p> > > then "yx" is rendered. I don't think it's described in the MathML REC, but I > suppose it is what the Bidi algorithm says? > If so, the following == reftest may make sense: <p> <math dir="rtl"><mi>x</mi></math> <math dir="rtl"><mi>y</mi></math> </p> <p> <math><mi>y</mi></math> <math><mi>x</mi></math> </p>

(In reply to Frédéric Wang from comment #59) > Regarding behavior of <math> element with dir="rtl", if we write: > > <p> > <math dir="rtl"><mi>x</mi></math> > <math dir="rtl"><mi>y</mi></math> > </p> > > then "yx" is rendered. I don't think it's described in the MathML REC, but I > suppose it is what the Bidi algorithm says? I assume this behaviour is because <math> is implemented using nsInlineFrame. I don't know what the appropriate behaviour should be. I wouldn't add a reftest unless it is clear what the behaviour should be. > > Joining algorithm inside a token frame was already implemented, but we don't > do it between MathML separate token frames. That sounds right to me. > So we can maybe write an != reftest like this (I hope arabic letters will > render correctly in Bugzilla): > > <math dir="rtl"><mtext>مجهول</mtext></math> (joined) > <math > dir="rtl"><mtext>م</mtext><mtext>ج</mtext><mtext>ه</mtext><mtext>و</ > mtext><mtext>ل</mtext></math> (disjoined) I think we have some tests for arabic joining in regular html text, though such tests can be quite dependent on which fonts are installed. I don't know how much value such a test might add. > For bidi inside token frames, an == reftest like this seems to work fine: > > <math dir="rtl"><mtext>و</mtext><mtext>ل</mtext></math> > <math><mtext>ول</mtext></math> I worry about adding such a test, even if the characters will never join, as a font may choose to apply kerning when the characters are in the same mtext.

Part 1 doesn't apply on tip...

(In reply to Boris Zbarsky (:bz) from comment #63) > Part 1 doesn't apply on tip... I forgot to say that patches from the bug it depends on (bug 534963) should be applied first.

Aha! That would do it. https://hg.mozilla.org/integration/mozilla-inbound/rev/e8809bd36bb0 https://hg.mozilla.org/integration/mozilla-inbound/rev/e604d9c39dd3 https://hg.mozilla.org/integration/mozilla-inbound/rev/15b3fb3e6f17

https://hg.mozilla.org/mozilla-central/rev/e8809bd36bb0 https://hg.mozilla.org/mozilla-central/rev/e604d9c39dd3 https://hg.mozilla.org/mozilla-central/rev/15b3fb3e6f17

(In reply to Frédéric Wang (:fredw) from comment #28) > > Something like that works: > > > > <mtext style="direction: rtl; font-family: 'XITS Math'">∛ب</mtext> > > > > Without the Arabic letter after the root it doesn't, but the same is true > > for text outside <math> so I guess it is a general bug on how the > > directionality of the text run is determined. > > OK, thanks for the info. If that's not what the specs say, can you please > open a separate bug stating that > > <span style="direction: rtl; font-family: 'XITS Math'">∛ب</span> > > works but not > > <span style="direction: rtl; font-family: 'XITS Math'">∛</span>? Based on bug 759284 comment 7, this can be fixed in the font, now both cases work with my work version of the font.