Description: https://drive.google.com/file/d/1Av8KnGTTVMYD5P7pEI7Pyv30rPPPEXpE/view?usp=sharing Steps to Reproduce: 1.Paste the text from outside LOffice 2. 3. Actual Results: Numbers' order swaps Expected Results: Correct order Reproducible: Always User Profile Reset: No Additional Info: In the video
Created attachment 204499 [details] Video
Created attachment 204500 [details] File in the video
repro in Version: 25.8.3.2 (X86_64) Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Hello Danat, The problem you're experiencing seems to be a failure to set the direction to right-to-left. Formatted text, in word processors like LibreOffice, always has a **Text direction** which is either Right-to-Left or Left-to-Right. This setting controls the relative order of individual characters within the overall sequence of characters. The buttons for controlling direction are available only if you enabled full support for RTL/CTL languages in Tools > Options > Languages & Locales > General. Here is what they look like: https://i.sstatic.net/kvwQs.png Now, in the text box in the browser, the direction is rendered as right-to-left - probably by auto-detection using the content. But the browser does not relate the direction information in the copied content, and LibreOffice does not perform direction auto-detection. Even ignoring the string you pasted - the rest of your document is _also_ in Left-to-Right direction, and you should change that. In fact, it is probably better for you to set your _paragraph styles_ to Right-to-Left direction. See also bug 157037 regarding autodetection.
(In reply to Eyal Rozenberg from comment #4) Thanks. I personally think that this could be improved, but up to you if don't regard it as a bug
(In reply to Danat from comment #5) > Thanks. I personally think that this could be improved, but up to you if > don't regard it as a bug Ok, let's talk about that... I mean, the important thing isn't whether this is marked as a bug or not, but whether and _how_ we can improve the situation. I agree that this could improve. There are two ways I can think of improving: 1. The full RTL-CTL support should be enabled automatically in more cases; this is meta-bug 164250. And, in fact, for 26.2 or 26.8, we will try enabling this _always_, and see what users think about that (we might get negative feedback from non-RTL users though). 2. When pasting text for which the direction is not specified - we should autodetect the direction. This is bug 157037 that I mentioned earlier. But that is not that simple, because if you paste just a few words into a paragraph that already has a direction - should it get "its own" direction? Should we surround the pasted text with Unicode control characters RLE/LRE and PDF? etc. those are my ideas. But maybe you were thinking about something else? Additional, or alternative? Please let me know
(In reply to Eyal Rozenberg from comment #6) It's mostly fine with Arabic, it pastes and gets the job done, but just this local inconvenience with braced numbers. Don't think that it should swap the position when pasting The program thinks those braced numbers or braced text in general are a different type of text while in reality it's the same and shouldn't be treated differently But it's hard for me to know what the program thinks exactly
(In reply to Danat from comment #7) > The program thinks those braced numbers or braced text in general are a > different type of text while in reality it's the same and shouldn't be > treated differently This happens because braces and digits are neutral characters: Their behavior is decided according to the direction. I'll attach a document to illustrate this in a moment.
Created attachment 204630 [details] Direction and alignment - effect on braces and digits This document uses the line of text shown in the opening video to illustrate how direction affects the behavior of "braced numbers" in lines of text both in English and in Arabic.
(In reply to Eyal Rozenberg from comment #9) Thanks for your help, appreciate that. I think it would be optimal to write code that doesn't treat braces as neutral And I also couldn't do the same with braced text, only numbers behave this way The program has quite a lot of behaviours that seem to be not consistently reproducible, and it's hard to know the mystery behind it Hope you'll implement a solution that is best for all
Danat, to change bug status, you need to establish that the change is merited. And even then, you can't just change it to whatever you like (e.g. NEW) - that requires confirmation by others. In this particular case, the behavior is appropriate: You're pasting plain text into a left-to-right paragraph and getting the correct order for such a paragraph. Again, if you expect auto-detection of direction - that is bug 157037.
(In reply to Eyal Rozenberg from comment #11) > Danat, to change bug status, you need to establish that the change is > merited. And even then, you can't just change it to whatever you like (e.g. > NEW) - that requires confirmation by others. In this particular case, the > behavior is appropriate: You're pasting plain text into a left-to-right > paragraph and getting the correct order for such a paragraph. Again, if you > expect auto-detection of direction - that is bug 157037. Ok, sorry. I do not abuse it, I only change status to "new" when somebody says they can reproduce the bug, and I almost never change it otherwise