Bug 129038 - Non-letter characters misaligned in bidi texts
Summary: Non-letter characters misaligned in bidi texts
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL Languages
  Show dependency treegraph
 
Reported: 2019-11-26 11:26 UTC by travis82
Modified: 2022-02-20 11:45 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Microsoft Office rendering (35.66 KB, image/png)
2021-03-29 20:06 UTC, Eyal Rozenberg
Details
Libreoffice rendering (47.98 KB, image/png)
2021-03-29 20:06 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description travis82 2019-11-26 11:26:15 UTC
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
Comment 1 Xisco Faulí 2019-11-28 12:09:10 UTC
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone
else confirms it.
Comment 2 Xisco Faulí 2020-04-06 15:13:48 UTC
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.
Comment 3 QA Administrators 2020-10-04 03:50:16 UTC Comment hidden (obsolete)
Comment 4 travis82 2020-10-04 05:56:48 UTC
The bug reproduced in LO 7.0.1.2 on Manjaro Linux. So I changed Status to UNCONFIRMED again.
Comment 5 Riyadh 2021-01-16 19:39:50 UTC
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.
Comment 6 Riyadh 2021-01-23 05:53:16 UTC
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
Comment 7 Riyadh 2021-01-23 06:02:56 UTC
Maybe someone on qa team will change status. Sorry.
Comment 8 Dieter 2021-01-23 10:21:39 UTC
(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.
Comment 9 Eyal Rozenberg 2021-03-29 20:03:24 UTC
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.
Comment 10 Eyal Rozenberg 2021-03-29 20:06:07 UTC
Created attachment 170814 [details]
Microsoft Office rendering
Comment 11 Eyal Rozenberg 2021-03-29 20:06:34 UTC
Created attachment 170815 [details]
Libreoffice rendering
Comment 12 Eyal Rozenberg 2021-03-29 20:11:23 UTC
I'm not 100% sure this should block language-detection, since it's more of a "don't force language detection" issue, but still.
Comment 13 travis82 2022-02-20 11:45:25 UTC
Here is a good document about the issue.

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/bidirectional-support