Description: When selecting placeholder fields in an RTL formula the incorrect element is highlighted for editing. This may or may not be related to the text formula representation using BiDi rendering. Depending on the type of formula being entered the text is either LTR or RTL which is confusing. Steps to Reproduce: 1. Open Math 2. Switch to RTL input 3. Chose any RTL function or operation 4. In the visual editor select the placeholder field 5. See which element is highlighted for editing in the text representation Actual Results: The wrong element is highlighted for editing. Expected Results: The selected item should be selected for editing Reproducible: Always User Profile Reset: No Additional Info: If you switch back to LTR input the field selection works as expected. Version 26.2 behaves as expected and all text representation are LTR. While the BiDi implementation in the text editing pane seems appropriate for RTL formulas the inconsistencies amongst formula types, i.e. formulas that start with strong RTL characters vs those that start with strong LTR characters will make it difficult to use.
Created attachment 206765 [details] RTL formula behavior 26.8 I have drawn an arrow on the element I selected. In the visual editor the dotted square is over a different element as is the blue highlight in the text representation.
Created attachment 206766 [details] RTL formula behavior 26.2 The selection behavior in 26.2 is as expected the selected element is the one that has the dotted square in the visual editor and blue highlight in the text editor.
Created attachment 206773 [details] Some prebuilt formulas that can be pasted into Math for testing
So this is a regression? Needs bisecting then.
I believe so since the selection works properly in 26.2. In 26.8 it affects the all the RTL scripts.
(In reply to Neil Patel from comment #5) > I believe so since the selection works properly in 26.2. In 26.8 it affects > the all the RTL scripts. Not seeing the issue on a recent build of 26.8 With smath set RTL and "XITS Math" set for 'Math' Font, and "XITS" set for 'Variables', the layout is the same as with a 26.2.2 release. But are you using a font supporting mirror (OTF "rtlm", or "rtla" feature)? As came up with see also bug 163329 =-testing-= Version: 26.8.0.0.alpha0+ (X86_64) Build ID: a9433c872b79f887e7faeed35d5e90739c5cd3e9 CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to V Stuart Foote from comment #6) > (In reply to Neil Patel from comment #5) > > I believe so since the selection works properly in 26.2. In 26.8 it affects > > the all the RTL scripts. > > Not seeing the issue on a recent build of 26.8 > > With smath set RTL and "XITS Math" set for 'Math' Font, and "XITS" set for > 'Variables', the layout is the same as with a 26.2.2 release. > > But are you using a font supporting mirror (OTF "rtlm", or "rtla" feature)? > As came up with see also bug 163329 > > =-testing-= > Version: 26.8.0.0.alpha0+ (X86_64) > Build ID: a9433c872b79f887e7faeed35d5e90739c5cd3e9 > CPU threads: 28; OS: Windows 11 X86_64 (build 26200); UI render: > Skia/Vulkan; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: CL threaded I am using a font with mirroring support. It's not the rendering that is misbehaving though. That is working correctly. It is what happens when you try to select a portion of the equation in the visual editor and that not lining up with the text representation. When composing a new equation, normally you can select the placeholder and begin typing your variables, etc. However, now when you select the placeholder and type the wrong piece gets edited.
(In reply to Neil Patel from comment #7) > I am using a font with mirroring support. It's not the rendering that is > misbehaving though. That is working correctly. It is what happens when you > try to select a portion of the equation in the visual editor and that not > lining up with the text representation. When composing a new equation, > normally you can select the placeholder and begin typing your variables, > etc. However, now when you select the placeholder and type the wrong piece > gets edited. OK sure, the Visual Edit mode has been badly broken, and caused a ruckus when we briefly made it the default mode. Don't think much has changed aside from the additional RTL Persian and Arabic, and now your Adlam and N'ko support. Isn't this a continuation/dupe of bug 160226?
Ahh, thanks. I didn't see bug 160226. It does seem related, though I am not familiar enough with the way selection works to know if it is the same exact failure mechanism. Interestingly the LTR visual editing seems to work properly even with the setting to disable it by default being off by default. I just tried editing RTL formulas in LTR mode then switching to RTL after composition is complete. That seems to work fairly well. FWIW, in RTL mode when you select elements in the visual editor they are highlighted in the exact opposite order in the latex editor. It is as if each element of a formula has an index and these are not inverted for RTL compositions. Though I am sure it is not that simple.
My guess would be some part of the code is working in RTL direction and some other part is (incorrectly) working in LTR direction. Bisecting can help finding out the commit that broke it.
Ok, thanks, I'll try to find a good commit and then bisect.
See https://wiki.documentfoundation.org/QA/Bibisect for how to bisect using binary builds corresponding to each commit (AKA bibisect).
(In reply to Khaled Hosny from comment #12) > See https://wiki.documentfoundation.org/QA/Bibisect for how to bisect using > binary builds corresponding to each commit (AKA bibisect). Thanks this should make things easier. I pulled the binary repo for 26.8 as referenced here https://wiki.documentfoundation.org/QA/Bibisect/Windows. I realize though that this is only the latest master. Where would I find the repo that contains the full history?
Nevermind. I checked the graph and I see the build history. I was thrown off because the oldest tag is not assigned.
I have determined this is not a regression. I tested the Windows 26.8 binary and the section works properly in Windows. This looks to be isolated to Linux. I went back through all the versions for Linux back to when the main RTL improvements were made in 24.2. https://bugs.documentfoundation.org/show_bug.cgi?id=134193 The selection issue was present after those patches.
(In reply to Neil Patel from comment #15) > I have determined this is not a regression. I tested the Windows 26.8 binary > and the section works properly in Windows. > > This looks to be isolated to Linux. I went back through all the versions for > Linux back to when the main RTL improvements were made in 24.2. > https://bugs.documentfoundation.org/show_bug.cgi?id=134193 > > The selection issue was present after those patches. What is strange is that you said in comment 2 "The selection behavior in 26.2 is as expected", so the problem should have appear in 26.8, but you also discovered that the problem apear first in 24.2. How is this possible?
(In reply to BogdanB from comment #16) > (In reply to Neil Patel from comment #15) > > I have determined this is not a regression. I tested the Windows 26.8 binary > > and the section works properly in Windows. > > > > This looks to be isolated to Linux. I went back through all the versions for > > Linux back to when the main RTL improvements were made in 24.2. > > https://bugs.documentfoundation.org/show_bug.cgi?id=134193 > > > > The selection issue was present after those patches. > > What is strange is that you said in comment 2 "The selection behavior in > 26.2 is as expected", so the problem should have appear in 26.8, but you > also discovered that the problem apear first in 24.2. How is this possible? Sorry for the confusion about that. The 26.2 results I had initially reported were on Windows. I hadn't considered that Linux version would act differently since RTL support had been around for a few versions.