Odd behavior in typing some characters in bidi texts

[hosein]

Hi
My english is not well and I’ll try my best to explain the issue that I have with LO.
I am Persian and my native language has RTL form. In Micorsoft Office, when I try to put an english word between persian words, by changing language layout, all of symbol and characters are treated as english character and are typed from Left to Right until I change the layout again and back to persian. In LO, even after changing the layout, some characters still remain RTl, this is strange and makes creating bidi texts in LO difficult. For better explanation please see the attached image.
I typed same bidi texts in MO and LO with same order of pressing keys. You can see the difference, LO treated some characters as if they have been typed with Persian keyboard and move these characters to the beginning of english text. This problem is happen for many characters and make creating bidi texts difficult. Is there solution to correct this behavior?

Thank you in advance and sorry for my english

[mikekaganski]

This could be a bug.

But before reporting it, first check if that is reproducible with latest releases (you forgot to mention which version of LO you use - and even which OS you use; I only guess it’s Windows by looking at the screenshots) no, LO screenshot doesn’t look like Windows…; and if you have Options▸Language Settings▸Languages▸Enhanced Language Support▸[] Ignore system input language unchecked.

[hosein]

No, this is on linux (i have this problem in all linux distros), these screenshots are from Mint 19.2 with Libreoffice 6.3.3. but this issue existed in older versions too. I confirm that I have "Ignore system input language " unchecked

[mikekaganski]

If you use LO on Linux, then your issue may be tdf#108151 - where Linux doesn’t provide a way to application to know which keyboard layout/input language is selected.

If you can, please compare the behaviour by installing LO on Windows, and typing there to see if the problem depends on that setting (ineffective on Linux) or not.

[hosein]

Checked. The problem also existed in LO 6.3.3 on Windows. This has nothing to do with Linux.

[gabix]

I can’t reproduce the above cases in LO 6.3.1 / Windows 7 except for the one with the number, i. e.

فازسی .058

As you see, the same problem in my browser.

However, here is what helps:

1. After switching to English (or another European language) and before continuing typing: Insert → Formatting mark → Left-to-right Mark.
2. After switching back to Persian and before continuing typing: Insert → Formatting mark → Right-to-left Mark.

Here is the result:

فازسی ‎.058‏

[hosein]

I confirm that this works. But is very tedious to do this procedure to write every english phrase in Persian texts.

[ajlittoz]

I personally don’t trust keyboard switching information being correctly reported back to LO or any application. Moreover, I consider it a nuisance: I am no professional typist, consequently I look at the keyboard to know where characters are “hiding”. I am really dependent on my physical keyboard. For me, it is a “neutral” device for entering characters, I don’t want it to be linked to a language. Mechanical keys are where they are and don’t move if I select another disposition.

I prefer to customise the keyboard tables to add unusual characters I need frequently on third or fourth modifier levels.

When I type multilingual text, I always explicitly mark sequences to the relevant language through a custom paragraph or character style.

However, for mixed LTR-RTL text, this is not enough if the “boundary” characters are not letters. This is is your case with $ or (). Non-letter characters are considered directional-neutral in Unicode. It is likely they receive the direction property of the underlying paragraph. Thus they are considered as Persion and jump to their correct position for Persion layout.

The only solution is to create a strong directionality barrier between the language sequences. See @gabix’s answer.

[mikekaganski]

I personally don’t trust keyboard switching information being correctly reported back to LO or any application

This could be because your usual writing doesn’t involve keyboard switching, which is common for most of locales in the world. Yet, for some locales, like Russian (having Cyrillic alphabet), it’s common to have at least 2 different keyboard layouts, and writing in own native language + some language using Roman alphabet, one necessarily switches keyboard (e.g., presses Shift+Alt) at every language switch. In this flow, your writing is clearly interspersed by a special kind of keyboard shortcut - that is just another shortcut you use when working. With this workflow, at any moment, your keyboard layout holds the information about the language you use.

[mikekaganski]

This scales naturally to having 3, 4, … keyboard layouts, even for languages that could use the same layout (in theory): yes, you can write both German and French using Intl layout - but having 2 separate layouts is very useful: this is explicit information that is easy to pass to any application you use (if it needs it). But it needs that workflow, that is not familiar to most people not using multiple keyboard layouts normally.

Unfortunately, Linux doesn’t seem to pass that info to applications; also unfortunately, LibreOffice doesn’t use that information to insert smart characters that @gabix mentioned, even in environment that does pass that information to the application (Windows).

[gabix]

having 2 separate layouts is very useful:

Sort of splitting hairs: not necessarily 2 separate layouts, but 2 (or 22) input languages. The same layout can be assigned to different languages as necessary.

that is not familiar to most people

Gimme a break. Most people do have to switch layouts/input methods: just count 1.5 bln people in China + roughly as many in India (with a hell of different scripts) + 200 mln (or more) speakers of languages using Cyrillic + as many (or even more) speakers of languages using Arabic.

[mikekaganski]

@gabix: you are absolutely correct wrt assigning input languages vs layouts - thank you for the correction! About “most” - my phrase was based on a recent article on habr.com (on discussion of it, even), where I took that impression that keyboard layout switching population is much smaller than I imagined. But I actually don’t have any strong evidence of my words, so you might be perfectly right here (can’t judge). Thank you for sharing this, too!

[ajlittoz]

I am not against layout switching. I just mean I want to have a visual cue about what I type. In the case of the Cyrillic keyboard you mention, I guess there is a secondary engraving on the vertical face of the keys. I once painted with permanent ink a second layout but the light did not fall well on the faces. I think an appropriate keyboard with legible engravings is a requirement. My dream is an electronic keyboard with small LCD or LED matrix on the key so that the layout could be uploaded to the keyboard and displayed in sync with the computer (imagine the advantage when pressing Alt Gr or various combinations and the keys really display the generated character – dreaming aloud).

[mikekaganski]

https://forums.crackberry.com/attachments/blackberry-concepts-dream-devices-f417/253133d1394088696t-q30-oled-keyboard-concept-optimus.jpg

[hosein]

Not that I have adapted myself with this issue by changing key sequences in LO. for instance I can write data() in RTL paragraphs if I type () first and then type data. But this solution is very cumbersome for complex texts and formulas and breaks compatibility with MO. Theoretically I see just one solution, as with MO, LO should treat non-letters characters like letters. What do you suggest? Should I report it as a bug?

[mikekaganski]

@hosein:

1. Of course, file this usability issue to bug tracker.
2. In the meanwhile, you could use Right-to-Left/Left-to-Right marks available in Customize menu - just assign some key combination to them, and use those on the boundaries as @gabix hinted.