Description: When adding Hebrew diacritic marks to words in an existing .doc file created in word (even if it is saved later as an .odt file or if the text was copy/pasted into an .odt file), the diacritic marks are misplaced. The do not appear in the letter, but rather a bit after it (to the left). A workaround is to delete the character, type it again and add the diacritic mark. This is similar to the problem that was resoved in bug #132688. Maybe the fix there was not comprehensive enough. This is also a regression from versions prior to 6.4.7. Adding Hebrew diacritics to long documents with no diacritics is actually a common task (and about half of my own job). This bug makes it practically impossible. Steps to Reproduce: 1. Make sure you have a Hebrew keyboard layout defined (no actual keyboard is needed). On linux+gnome this is done through the language & area settings: add the Hebrew (lyx) keyboard layout. 2. Open the attached document, and set the input language to Hebrew 3. Place the caret after the first letter (Hebrew is RTL, so this means to the left of the rightmost character, כ) and add the Hebrew diacritic mark Kamatz (Shist+E). Actual Results: The kamatz is added incorrectly, somewhat after the character כ. Expected Results: The kamatz is added correctly, directly underneath the character כ (it should look like this: כָ). Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.1.1 / LibreOffice Community Build ID: 10(Build:1) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: he-IL (he_IL.UTF-8); UI: he-IL Ubuntu package version: 1:7.1.1~rc1-0ubuntu0.21.04.1~lo2 Calc: threaded
Created attachment 170000 [details] Bugged when adding Hebrew diacritic marks.
I attach another file which demonstrates the same behaviour.
Created attachment 173060 [details] If you add vowel marks, they will be displaced
Confirmed the bug with the first attached document; I did not understand what I'm supposed to do with the second one. Version: 7.0.4.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-US (en_IL); UI: en-US Debian package version: 1:7.0.4-4
Actually I can't reproduce it any more with 7.2.2.2 on Ubuntu. Could it be solved by itself?
(In reply to Yotam Benshalom from comment #5) > Actually I can't reproduce it any more with 7.2.2.2 on Ubuntu. Could it be > solved by itself? It might be that a developer fixed the issue based on some other report. We can close as worksforme in this case.
Can no longer reproduce with: Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: 5c68399e6bea3aa18477487400f8bb143d6ed84e CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US but, Buovjaga, shouldn't this be marked FIXED?
(In reply to Eyal Rozenberg from comment #7) > Can no longer reproduce with: > > Version: 7.5.0.0.alpha0+ / LibreOffice Community > Build ID: 5c68399e6bea3aa18477487400f8bb143d6ed84e > CPU threads: 4; OS: Linux 5.18; UI render: default; VCL: gtk3 > Locale: en-IL (en_IL); UI: en-US > > but, Buovjaga, shouldn't this be marked FIXED? It can be marked as fixed, if someone discovers the commit that fixed it. This can be done by bibisecting with reversed good/bad.