Description: As I described here with pics: https://ask.libreoffice.org/en/question/216996/odd-behavior-in-typing-some-characters-in-bidi-texts/ The problem occurs when users try to put ltr phrases in rtl paragraphs or vice versa, if the boundary characters consists of non-letters characters, they receive the direction property of the underlying paragraph. This leads to misaligned characters in phrase. A temporary solution is creating a strong directionality barrier between the language sequences using Insert → Formatting mark → Left-to-right mark (this won't work in the first line of paragraph tough, why? I don't know) Long-term solution treating non-letters characters as letters in LO. This is what Microsoft office does Steps to Reproduce: 1. create a rtl paragraph and write something 2. change keyboard layout and write and ltr word that negins with $ (for expample) 3. Actual Results: $ will be misaligned and locates at the end of ltr word Expected Results: it should locate at the beginning of the word Reproducible: Always User Profile Reset: No Additional Info: s
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
Thank you for reporting the bug. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear travis82, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
The bug reproduced in LO 7.0.1.2 on Manjaro Linux. So I changed Status to UNCONFIRMED again.
OS: Win 10 (x64) Language: Arabic (with English text for bidi test) I tested this on: Release 7.0.4.2 (x64) and RC2 7.1.0.1 (x64). In both I got the same result.
Reproduced on: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: ar-IQ (ar_IQ); الواجهة: ar-SA Calc: CL Version: 7.1.0.1 (x64) Build ID: b585d7d90ab863bf29b2d110c174c0c2a98f3ee4 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: ar-IQ (ar_IQ); UI: ar-SA Calc: CL Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: en-US (ar_IQ); UI: ar-SA Calc: CL
Maybe someone on qa team will change status. Sorry.
(In reply to Riyadh from comment #7) > Maybe someone on qa team will change status. Sorry. I don't have to say sorry. If you can confirm a bug, you are allowed to change status to NEW.
travis82, what you are describing is not in itself a bug. Le me rephrase your reproduction instructions: 1. In an RTL paragraph, enter some RTL text. 2. Enter a directionality-neutral character. 3. Enter some LTR text. Why should the neutral character be part of the LTR run, rather than the RTL run? It _should_ be the case that the paragraph direction decides here. If I am not mistaken, what you are actually complaining about is how, when one changes the keyboard input language from an RTL to an LTR one, LO ignores the user's intent of inserting LTR text. I believe that is the difference between LO and MS Office your Ask.LO post describes.
Created attachment 170814 [details] Microsoft Office rendering
Created attachment 170815 [details] Libreoffice rendering
I'm not 100% sure this should block language-detection, since it's more of a "don't force language detection" issue, but still.
Here is a good document about the issue. https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/bidirectional-support
So basically MS has its own non-standard bidirectional text algorithm. We can’t implement that, not by default anyway. If we want to follow MS here it would be as some sort of compatibility mode for MS file format and may be and ODF option as well. The very first step would to find an exact detailed documentation of MS algorithm, or someone volunteers to reverse engineer it and provide such documentation. My personal position is that Unicode bidi algorithm have enough provisions to “capture user intent”, we need more ergonomic ways to utilize them.
MS behaviour depends heavily on keyboard input, if you copy the exact same text from a web page it will show it like LO. Which is another advantage of the Unicode’s implicit way of handling this using control characters; the “user intent” is captured in the text itself, not external to it.