208309 - there is no Bidi/Joining algorithm on Arabic/Persian texts in MathML

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[Behnam Esfahbod [:zwnj]]

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.

Comment 1

[Behnam Esfahbod [:zwnj]]

Attachment: Persian/Arabic text in MathML

Screenshot of Persian (farsi) text example in MathML with Mozilla 1.3.1 on MS
WinXP.

Comment 2

[Simon Montagu :smontagu]

Confirming.

Comment 3

[rbs]

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.

Comment 4

[Behnam Esfahbod [:zwnj]]

Attachment: 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.

Comment 5

[Simon Montagu :smontagu]

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).

Comment 6

[rbs]

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.

Comment 7

[Behnam Esfahbod [:zwnj]]

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

Comment 8

[Behnam Esfahbod [:zwnj]]

Attachment: Sample-1 on FireFox 0.9.3

There's no Bidi/Shaping on arabic/persian texts in mathml on firefox.

Comment 9

[Behnam Esfahbod [:zwnj]]

Attachment: 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)

Comment 10

[Behnam Esfahbod [:zwnj]]

Attachment: 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.

Comment 11

[Behnam Esfahbod [:zwnj]]

Attachment: 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+

Comment 12

[Behnam Esfahbod [:zwnj]]

Attachment: Test case

Upload the test case to make up2date screenshots.

Comment 13

[Behnam Esfahbod [:zwnj]]

Needs reassign?

Comment 14

[Behnam Esfahbod [:zwnj]]

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

Comment 15

[Simon Montagu :smontagu]

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.

Comment 16

[Frédéric Wang (:fredw)]

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

Comment 17

[Frédéric Wang (:fredw)]

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

Comment 18

[Karl Tomlinson (:karlt)]

(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.

Comment 19

[Frédéric Wang (:fredw)]

> 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.

Comment 20

[Frédéric Wang (:fredw)]

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...

Comment 21

[Frédéric Wang (:fredw)]

Attachment: 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.

Comment 22

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math (V2)

Comment 23

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math (V3)

Comment 24

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math (V4)

Comment 25

[Khaled Hosny]

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

Comment 26

[Frédéric Wang (:fredw)]

(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.

Comment 27

[Khaled Hosny]

(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.

Comment 28

[Frédéric Wang (:fredw)]

> 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>?

Comment 29

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 1 (V5)

Comment 30

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 2 (V5)

Comment 31

[(no longer active)]

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

Comment 32

[Frédéric Wang (:fredw)]

Testcase from the MathML testsuite:

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

Comment 33

[Frédéric Wang (:fredw)]

Attachment: screenshot of Maghreb1 with patches from this bug and mathml-dir applied.

Comment 34

[(no longer active)]

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.

Comment 35

[Frédéric Wang (:fredw)]

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.

Comment 36

[(no longer active)]

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).

Comment 37

[Frédéric Wang (:fredw)]

(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"

Comment 38

[Frédéric Wang (:fredw)]

> 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.

Comment 39

[(no longer active)]

(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?

Comment 40

[Frédéric Wang (:fredw)]

(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.

Comment 41

[Frédéric Wang (:fredw)]

Attachment: screenshot of the testcase

Comment 42

[(no longer active)]

Great, thanks for the clarification!

Comment 43

[Bill Gianopoulos [:WG9s]]

(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.

Comment 44

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 1 (V6)

Comment 45

[Karl Tomlinson (:karlt)]

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 # &CounterClockwiseContourIntegral;

>+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.

Comment 46

[Karl Tomlinson (:karlt)]

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

Comment 47

[Frédéric Wang (:fredw)]

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

Comment 48

[Frédéric Wang (:fredw)]

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

Comment 49

[Frédéric Wang (:fredw)]

(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.

Comment 50

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 1 (V7)

Comment 51

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 2 (V6)

Comment 52

[Frédéric Wang (:fredw)]

Attachment: 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 53

[Karl Tomlinson (:karlt)]

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.

Comment 54

[Frédéric Wang (:fredw)]

Attachment: Mirroring of operators for arabic math - part 1 (V8)

Comment 55

[Frédéric Wang (:fredw)]

(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

Comment 56

[Frédéric Wang (:fredw)]

Attachment: reftests (V2)

Comment 57

[Karl Tomlinson (:karlt)]

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.

Comment 58

[Frédéric Wang (:fredw)]

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

Comment 59

[Frédéric Wang (:fredw)]

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>

Comment 60

[Frédéric Wang (:fredw)]

> (we don't join x and y in the example above).

I meant in <math><mi>x</mi><mi>y</mi></math>

Comment 61

[Frédéric Wang (:fredw)]

(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>

Comment 62

[Karl Tomlinson (:karlt)]

(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.

Comment 63

[Boris Zbarsky [:bzbarsky]]

Part 1 doesn't apply on tip...

Comment 64

[Frédéric Wang (:fredw)]

(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.

Comment 65

[Boris Zbarsky [:bzbarsky]]

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

Comment 66

[Ed Morley [:emorley]]

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

Comment 67

[Khaled Hosny]

(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.