Created attachment 196930 [details] Flipped-direction square-root stem rendering Consider attachment 189693 [details] (from bug 111705 regarding Arabic math expressions). LO Formula Editor can render it, for the most part, but - look at the square root stems! Instead of: _____ \ \/ we have: _____ / \/ i.e. the stem is drawn on the right side of the "roof" part, which is ok, but it's drawn as though the roof is to its right, not its left. Screenshot attached. Seen with: Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Ubuntu package version: 4:24.8.1-0ubuntu0.22.04.1~lo1 Calc: threaded
Created attachment 196932 [details] Screenhot with XITS Math installed The document sets Math font to XITS Math[1], you need to have this font installed (Math being Math, its font dialog does not give any indication whether the set font is installed or not). There are very few fonts that support Arabic math, XITS Math is one of them, and the other is the latest version of Noto Sans Math[2]. [1] https://github.com/aliftype/xits/releases/tag/v1.302 [2] https://github.com/notofonts/math/releases/tag/NotoSansMath-v3.000
Created attachment 196933 [details] Screenshot with all fonts set to Noto Sans Math Here how it looks if I change all math font settings to use Noto Sans Math.
Created attachment 196934 [details] Document that use Noto Sans Math Here is the document from last screenshot.
(In reply to خالد حسني from comment #1) Hmm... Why is the sqrt stem even a glyph at all? That doesn't sound right. But be that as it may - if a glyph is _missing_, I'm fine with being given an error message, or the glyph being replaced with an empty rectangle, or something along those lines. But why would a flipped glyph - another glyph - be used instead?
(In reply to Eyal Rozenberg from comment #4) > (In reply to خالد حسني from comment #1) > > Hmm... Why is the sqrt stem even a glyph at all? That doesn't sound right. It is not, it is a drawn member of a node. > > But be that as it may - if a glyph is _missing_, I'm fine with being given > an error message, or the glyph being replaced with an empty rectangle, or > something along those lines. But why would a flipped glyph - another glyph - > be used instead? The sm Formula editor composes into nodes--for roots stems are drawn as needed and are appended to the radical to create the notation for a root. That allows the radical to vary in size as needed to fit the node. With the introduction of RTL support to sm (and refactoring needed to allow use of fonts other than OpenSymbol) the stems are correctly reversed / positioned for RTL--but if the radical glyph (U+221A) doesn't support the reversed alternate, the node is visually wrong, but correct in RTL size and placement.
(In reply to V Stuart Foote from comment #5) > for roots stems are drawn as needed and are appended to the radical to create the notation for a root. The more correct term to "stem" would be "vinculum" used with roots, or more generally "overline" for things like negation. In sm they are drawn elements of a node, not a Unicode glyph. But I see I misread the initial issue, and concern was with the "radical" reversing/mirroring. Adjusted the summary. Sorry for the noise otherwise, as Khaled is correct that with a supported font the radical reverses, eg. Noto Sans Math. Enhancement might be to enable RTL mirror for the U+221A glyph in OpenSymbol font.
(In reply to V Stuart Foote from comment #6) > Sorry for the noise otherwise, as Khaled is correct that with a supported > font the radical reverses, eg. Noto Sans Math. Well, two points. First - I didn't set the font. And even if I don't use Khaled's document, but rather just: 1. Create a new formula 2. Set the direction to RTL 3. Insert a square root construct (under "Functions") I get the flipped "radical". LibreOffice' default font can't produce incorrectly-rendered radicals. And whatever one sets the font to - drawing a flipped radical is a bug, plain and simple. Either we can draw the formula right, or we refuse to use the typeface, or we refuse to render just the radical. Based on what's been written so far - please confirm the bug. Second: Do "supported fonts" have a different glyph for the RTL radical? I can't seem to find one in Noto Sans Math. Or is it a "mirrored depending on direction" feature of the glyph? > Enhancement might be to enable RTL mirror for the U+221A glyph in OpenSymbol > font. s/enhancement/bug fixed or workaround/ ...
(In reply to Eyal Rozenberg from comment #7) > (In reply to V Stuart Foote from comment #6) > > Sorry for the noise otherwise, as Khaled is correct that with a supported > > font the radical reverses, eg. Noto Sans Math. > > Well, two points. > > First - I didn't set the font. And even if I don't use Khaled's document, > but rather just: > > 1. Create a new formula > 2. Set the direction to RTL > 3. Insert a square root construct (under "Functions") > > I get the flipped "radical". LibreOffice' default font can't produce > incorrectly-rendered radicals. And whatever one sets the font to - drawing a > flipped radical is a bug, plain and simple. Either we can draw the formula > right, or we refuse to use the typeface, or we refuse to render just the > radical. Based on what's been written so far - please confirm the bug. > But it is not a bug. If the font supports mirror (OTF "rtlm", or "rtla" feature) for U+221A the character is reversed as the node is composed. Listing of Unicode where font designer can specify rtlm mirror: https://www.charactercodes.net/mirrored/ https://www.compart.com/en/unicode/mirrored > Second: Do "supported fonts" have a different glyph for the RTL radical? I > can't seem to find one in Noto Sans Math. Or is it a "mirrored depending on > direction" feature of the glyph? > Nope, they're the same radicals (U+221A, U+221B, U+221C) that can be mirrored "rtlm", or an alternate glyph "rtla" is provided that is directional aware. And will display in an application that supports it (as LibreOffice now does). But the font designer has to add the "gsub" table entry. > > Enhancement might be to enable RTL mirror for the U+221A glyph in OpenSymbol > > font. > > s/enhancement/bug fixed or workaround/ ... Nope, up until Khaled implemented Arabic symbols and RTL math notation at 24.2 the sm formula & OLE would not reverse at all. Correcting OpenSymbol now to deliver "rtlm" mirror, or "rtla" alternate, tables would be reasonable implementation/enhancement. But it is not a bug. Nor is there a bug in the implementation as it does what it is supposed to--when the font supports the feature.
(In reply to V Stuart Foote from comment #8) > But it is not a bug. If the font supports mirror (OTF "rtlm", or "rtla" > feature) for U+221A the character is reversed as the node is composed. These are implementation details. I start LibreOffice - without having messed it up in any way - try to write a formula with a square root, and it is rendered flipped. That is not what I wanted and not what I "told" LibreOffice to do. Hence, a bug. > Nor is there a bug in the implementation as it does what it is supposed > to--when the font supports the feature. The implementation is supposed to render formulae correctly. At a lower level, there is an assumption that the radical will be flipped as necessary, which is an invalid assumption. If we can fix it by making the assumption valid, great. I still think that if a font is deficient for formula rendering, LO Math should say something to the user about this. Naturally the default should just work; but since we have the ability to switch fonts, the app should tell us whether we've made a valid choice or whether it will bite us in the *** later on. > Nope, up until Khaled implemented Arabic symbols and RTL math notation at > 24.2 the sm formula & OLE would not reverse at all. I just want to clarify that I am very appreciative of Khaled's efforts, and am not claiming he's done anything wrong. It's just that the current state of affairs we have a new feature which has a bug.
(In reply to Eyal Rozenberg from comment #4) > (In reply to خالد حسني from comment #1) > > Hmm... Why is the sqrt stem even a glyph at all? That doesn't sound right. What else would it be? > But be that as it may - if a glyph is _missing_, I'm fine with being given > an error message, or the glyph being replaced with an empty rectangle, or > something along those lines. But why would a flipped glyph - another glyph - > be used instead? There is no dedicated Unicode code point for right to left radical. The same code point is used for left-to-right and right-to-left glyph, like how opening parenthesis are the same code point and for right-to-left text is becomes a right parenthesis and for left-to-right text it becomes a left one. Unlike parenthesis, though, where there is a pair of mirrored Unicode code point and the text layout engine can switch them regardless of the font, there is only one radical, so the font needs to provide a right-to-left alternate glyph using “rtlm” feature, so detecting such support at the font level is more involved that simple Unicode code point coverage that is usually done. Note this does not affect only radicals, in your screenshot the integrals and the summation are not mirrored as well, but they should. We could warn, may be in an info bar, if the font used for RTL math does not have an rtlm feature (though a font might have the feature and still not cover the required glyph, we can also detect that, but it is also more work). We can apply affine transformation to the glyphs if the font does not mirror them, but the above caveat applies, in addition to the fact that simple affine transformation is not always right, in a glyph like ∲ (clockwise contour integral) the integral part should be mirrored but the circled arrow must remain clockwise or it becomes ∳ (counterclockwise contour integral). The last option is to add mirrored glyphs and rtlm feature to OpenSymbol. That would be a big change though, since OpenSymbol right now does not have any OpenType feature and I don’t know if adding any would have any unwanted side effects.