Labels in menus and dialogs are typically rendered with an underline under a letter corresponding to a shortcut key. In the Arabic UI (and maybe other CTL languages), the rendering is not merely of an underlining of one letter, but rather of a breaking of the connected sequence of letters, e.g. if we underline the 7ah, the second letter, in: تحرير we get: تحرير plus the underline. I simulated the effect using ZWNJ's. This severely hurts readability. AFAICR, it's not the custom in other apps.
Created attachment 201866 [details] LO 26.2 Calc with Arabic UI; note menu label rendering
This looks like a regression.
(In reply to Khaled Hosny from comment #2) > This looks like a regression. Or may be not. Are you using GTK or QT/KDE plugin?
(In reply to Khaled Hosny from comment #3) > Or may be not. Are you using GTK or QT/KDE plugin? You are absolutely right to ask that, sorry. I am seeing this with: Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7ef1c437f30b0869a5b9fa33809bac2c6665ace3 CPU threads: 4; OS: Linux 6.12; UI render: default; VCL: qt5 (cairo+xcb) Locale: en-IL (en_IL); UI: ar-SA Calc: CL threaded but _not_ seeing this with GTK3 (which has underlining only when I press the Alt key, but the underlining looks fine). So, I don't remember whether the QT5 VCL had this before or not.
It appears to be a Qt bug https://bugreports.qt.io/browse/QTBUG-93371. Can you test with other Qt applications?
(In reply to Khaled Hosny from comment #5) > It appears to be a Qt bug https://bugreports.qt.io/browse/QTBUG-93371. Can > you test with other Qt applications? Tested, and it does happen, for example, with Kate on my machine: Devuan GNU/Linux Excalibur (~= Debian Trixie without systemd) Qt6 version: 6.8.2 Kate version: 25.04.2 (which uses Qt 6)
NOTOURBUG then? I don’t know much about Qt and how it is used in LibreOffice and whether it is possible to workaround this issue, by, for example disabling the underline by default for Arabic at least, though I expect that other scripts are also affected, since this is not just a readability issue, but the text is effectively mangled/
(In reply to Khaled Hosny from comment #7) So, technically it is NOTOURBUG, but like you said, maybe we should consider a workaround. Let's ask for advice for now.
I'm not an expert on Arabic, but I found it to work fine in version 6.1.8.
(In reply to Saburo from comment #9) > I'm not an expert on Arabic, but I found it to work fine in version 6.1.8. Oh, typo. 6.1.8 --> 6.1.6 But, bibisect repository linux-64-6.2 is good. linux-64-6.3 is good. linux-64-25.2 is bad. I'm sure I can bisected somewhere.
linux-64-6.3master good إصدارة: 6.3.7.0.0+ معرّف البناء: 726535ec30f12697ceccd2f0640d9371a64dc5bd خيوط المعالج: 4; نظام التَّشغيل: Linux 6.5; مصيّر الواجهة: المبدئيّ; VCL: gtk3; المحليّة: ja-JP (ja_JP.UTF-8); لغة الواجهة الرسومية: ar-SA Calc: threaded linux-64-6.4oldest bad Version: 6.3.0.0.alpha1+ Build ID: c98b1f1cd43b3e109bcaf6324ef2d1f449b34099 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: kde5; Locale: ja-JP (ja_JP.UTF-8); UI-Language: ar-SA Calc: threaded I was unable to bibisect.
(In reply to Saburo from comment #11) > linux-64-6.3master > good > إصدارة: 6.3.7.0.0+ > معرّف البناء: 726535ec30f12697ceccd2f0640d9371a64dc5bd > خيوط المعالج: 4; نظام التَّشغيل: Linux 6.5; مصيّر الواجهة: المبدئيّ; VCL: > gtk3; > المحليّة: ja-JP (ja_JP.UTF-8); لغة الواجهة الرسومية: ar-SA > Calc: threaded > > linux-64-6.4oldest > bad > Version: 6.3.0.0.alpha1+ > Build ID: c98b1f1cd43b3e109bcaf6324ef2d1f449b34099 > CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: kde5; > Locale: ja-JP (ja_JP.UTF-8); UI-Language: ar-SA > Calc: threaded > > I was unable to bibisect. The difference in the VCL UIs might explain the inability to bibisect. Saburo: you can force a UI with: SAL_USE_VCLPLUGIN=kde5 instdir/program/soffice In comment 4 we see VCL: qt5, which is unusual as that backend should not be used in production, but if the issue is seen with kf5/kf6, then it doesn't matter.
(In reply to Buovjaga from comment #12) > In comment 4 we see VCL: qt5, which is unusual as that backend should not be > used in production, but if the issue is seen with kf5/kf6, then it doesn't > matter. Well, we may not want for it to be used in production, but that's what we're building our nightlies: https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb99-TDF/current/ to offer. If I try to choose kf5/kf6, I just get gtk3 as a fallback. If we were to build DEBs with kf5/kf6 support (or even gtk4 for that matter), I could try that.
(In reply to Eyal Rozenberg from comment #13) > (In reply to Buovjaga from comment #12) > > In comment 4 we see VCL: qt5, which is unusual as that backend should not be > > used in production, but if the issue is seen with kf5/kf6, then it doesn't > > matter. > > Well, we may not want for it to be used in production, but that's what we're > building our nightlies: > > https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@tb99- > TDF/current/ > > to offer. If I try to choose kf5/kf6, I just get gtk3 as a fallback. If we > were to build DEBs with kf5/kf6 support (or even gtk4 for that matter), I > could try that. Then something has gone wrong, maybe with the upgrade to AlmaLinux 9 in our infra. Bibisect repos certainly used to be built with kf5 (but not with kf6 and that was starting to become a problem).
My comments 9 and 10 were incorrect. Version 6.1.6 used gtk2. Also, even when I started it with SAL_USE_VCLPLUGIN=kde5 ./instdir/program/soffice.bin, it still used gtk3. إصدارة: 6.1.6.3 معرّف البناء: 5896ab1714085361c45cf540f76f60673dd96a72 خيوط المعالج: 4; نظام التَّشغيل: Linux 6.5; مصيّر الواجهة: المبدئيّ; VCL: gtk2; المحليّة: ja-JP (ja_JP.UTF-8); Calc: group threaded
If Qt is to blame we cannot do much, so NOB. At least no question for UX.
(In reply to Heiko Tietze from comment #16) > At least no question for UX. The UX question is: Given that the current rendering is te-rri-ble (!) - what's better: * Draw the menus _without_ separating the underlined letter, possibly even without the underline, with qt5 VCL (maybe qt6 too, don't know) * Think of some other workaround for marking the shortcut letter (perhaps a different background color? emboldening? It has to be something that won't break the word apart though) * Do nothing and wait for the QT people to fix this.
(In reply to Eyal Rozenberg from comment #17) > The UX question is: Given that the current rendering is te-rri-ble (!) - > what's better: > > * Draw the menus _without_ separating the underlined letter, possibly even > without the underline, with qt5 VCL (maybe qt6 too, don't know) > * Think of some other workaround for marking the shortcut letter (perhaps a > different background color? emboldening? It has to be something that won't > break the word apart though) > * Do nothing and wait for the QT people to fix this. As an alternative, I think the best option would be to contribute to Qt and fix this. Qt is an open source project welcoming contributions, as is LibreOffice. I've made very positive experiences contributing to Qt, but the matter at hand here is unfortunately outside of my expertise, so it would be great if somebody more qualified could take a look.
(In reply to Eyal Rozenberg from comment #17) > * Draw the menus _without_ separating the underlined letter, possibly even > without the underline, with qt5 VCL (maybe qt6 too, don't know) This would be a quick and easy solution. Fixing the Qt bug is better, of course.
(In reply to Heiko Tietze from comment #19) That sounds reasonable, but I'll create a poll on the Arabic UI Telegram group. Perhaps someone would like to do the same for Farsi? Hossein maybe?
(In reply to Michael Weghorn from comment #18) > As an alternative, I think the best option would be to contribute to Qt and > fix this. Qt is an open source project welcoming contributions, as is > LibreOffice. > I've made very positive experiences contributing to Qt, but the matter at > hand here is unfortunately outside of my expertise, so it would be great if > somebody more qualified could take a look. Usually these kinds of bugs happen (and stick around for many years) because of unfortunate decisions made early in a project. I can take a quick look at Qt's code, but I can't promise anything.