In bug 208309, I have introduced a small hack to mirror some large/stretchy operators using a scale transform. This does not work in general (e.g. clockwise integral) so it would be better to use the glyphs and constructions available in some fonts like XITS.

As I see in XITS this will require a way to get the index of a mirrored glyph from the index of the initial glyph (XITS uses the rtlm substitution table). I guess there is something in gfx/ to do that.

Note that the implementation of rtlm feature in XITS is currently not in accordence with the spec; it lists all mirrored glyphs while it should only list ones not covered by a fixed list defined in the OpenType spec, since the OpenType engine should mirror the ones on that list even if the font does not have an rtlm feature. So, I think the proper way here is to shape the string normally with RTL direction, then extract the glyph indices for any further operations (getting big operator variants from the MATH table, etc.)

Quick test that does not work. Probably I need to call ShapeText on the gfxTextRun to get the mirrored glyph.

So actually the previous patch worked for mirrorable Unicode characters. But not for the glyphs specific to the XITS fonts. http://www.maths-informatique-jeux.com/ulule/mathml_torture_test/rtl.html IIUC, gfxTextRun automatically shapes the text. I also tried with a ShapedTextWord but that did not help much.

This patch now sets rtlm feature tag and that seems to work with XITS to mirror sums, integrals, radicals etc For unicode characters already covered by the Open Type spec (e.g. parenthesis, brackets or braces) since XITS also lists them in rtlm substitutions, there is some kind of "double mirroring" happening and so we end up with the wrong character. For other fonts without rtlm feature, the characters covered by the Open Type spec are mirrored correctly. The patch disables the mirroring via scale transform for other characters. I think it becomes a bit difficult to track which glyph has been successfully mirrored by rtlm or normal bidi, the scale to apply, whether a scale is not allowed (e.g. for clockwise integral), the reference point (left or right) etc I believe our MathML bidi implementation has had limited use so far, so perhaps we can just drop mirroring via scale transform and ask users to install relevant fonts like XITS if needed. That would allow to clean up the code.

This is an attempt to refresh the patch. However, there are some problems with the horizontal position of some mirrored operators. (Also, there is still the issue of whether we want to keep the fallback scale transform.)

(In reply to Frédéric Wang (:fredw) |away 27/04 to 06/05 from comment #6) > This is an attempt to refresh the patch. However, there are some problems > with the horizontal position of some mirrored operators. The issue I had here is that the start horizontal position of character-level mirroring (e.g. parenthesis) and glyph-level mirroring (rtlm) is different. I didn't see it before because XITS used rtlm in all cases. That will probably require some special handling to distinguish the two cases... @Khaled: feel free to look into this bug and/or take it if you wish. It should now be relatively independent from the other MathML bugs that I want to fix first. (Note: if we don't want to keep the scale transform fallback for mirroring, the whole nsMathMLOperators::IsMirrorableOperator stuff can be removed too)

(In reply to Frédéric Wang (:fredw) |away 27/04 to 06/05 from comment #7) > (Note: if we don't want to keep the scale transform fallback for mirroring, > the whole nsMathMLOperators::IsMirrorableOperator stuff can be removed too) I think one option to consider to replace the negative scale fallback would be to add some logic to check if glyph-level mirroring fails for some operators that are expected to be mirrorable (e.g. big sum or integrals), so that we could then connect it to the "missing fonts" notification and give the user the possibility to install XITS. We can also keep this scale fallback, but I actually had the same issues with the inconsistent horizontal positions. So that would be another case to handle.

Refreshing patch.

Trying to fix the horizontal positioning issue (still problems with some sizes for square roots...).

So the inconsistent horizontal positioning was due to the fact that the rtlm mirroring failed for large operator (but not for radicals) and so the scale transform was used. I need to debug a bit to understand. This patch tries to keep the mirroring via the scale transform.

So as I said in comment 11 and during the MathML meeting, there was something weird happening with the mirroring that I couldn't understand without further debugging. So as I recall, the patch didn't work perfectly. As I don't have much time to work on MathML developments, I'm resetting the "assigned" field. Feel free to work on that bug if you wish.