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.
(In reply to Jonathan Clark from comment #21) > 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. That's great, thanks a lot! And it's fair of course to say it might be more effort than you can spend on this now. The Qt issues linked in "See Also" have some information.
Created attachment 202253 [details] Work-in-progress qt6 patch As far as I can tell, this should be a one-line fix. There are comments on those bugs suggesting it would be a significant effort though, so maybe I'm overlooking something.
(In reply to Jonathan Clark from comment #23) > As far as I can tell, this should be a one-line fix. That one-line looks promising :-) However - even if this is the fix, it's not going in QT5; and even if it did, it may not be going into OS distributions already released. So, at least for the near future, a workaround still remains relevant. Probably.
(In reply to Jonathan Clark from comment #23) > Created attachment 202253 [details] > Work-in-progress qt6 patch > > As far as I can tell, this should be a one-line fix. There are comments on > those bugs suggesting it would be a significant effort though, so maybe I'm > overlooking something. Awesome, thanks! Would you feel comfortable to submit that to Qt's Gerrit as described at https://wiki.qt.io/Qt_Contribution_Guidelines and then the people knowledgeable in that area can review/give feedback? (In reply to Eyal Rozenberg from comment #24) > However - even if this is the fix, it's not going in QT5; and even if it > did, it may not be going into OS distributions already released. So, at > least for the near future, a workaround still remains relevant. Probably. Out of curiosity: Is there any particular reason to use the qt5/kf5 VCL plugin over the gtk3 one, or could using gtk3 be a reasonable workaround until the fix is available? Doesn't using KDE Plasma (for which kf5 would be picked by default for LO) result in the problem showing all over the places in the desktop and KDE applications, as KDE Plasma itself is based on Qt?
(In reply to Michael Weghorn from comment #25) > Awesome, thanks! Would you feel comfortable to submit that to Qt's Gerrit as > described at https://wiki.qt.io/Qt_Contribution_Guidelines and then the > people knowledgeable in that area can review/give feedback? Yes. I can look into that early next week. > (In reply to Eyal Rozenberg from comment #24) > > However - even if this is the fix, it's not going in QT5; and even if it > > did, it may not be going into OS distributions already released. So, at > > least for the near future, a workaround still remains relevant. Probably. > > Out of curiosity: Is there any particular reason to use the qt5/kf5 VCL > plugin over the gtk3 one, or could using gtk3 be a reasonable workaround > until the fix is available? > Doesn't using KDE Plasma (for which kf5 would be picked by default for LO) > result in the problem showing all over the places in the desktop and KDE > applications, as KDE Plasma itself is based on Qt? Yes, it happens throughout KDE. Even in English, tapping the alt key makes some text vibrate due to this bug.
(In reply to Jonathan Clark from comment #26) > Yes. I can look into that early next week. Great, thanks a lot. > Yes, it happens throughout KDE. Even in English, tapping the alt key makes > some text vibrate due to this bug. Then I tend to suggest to not do any workarounds in the qt5/qt6 VCL plugins in LibreOffice for now, as using gtk3 seems to be a reasonable workaround and if the issue is so critical, I would expect that users severely affected by this bug probably wouldn't use KDE/Qt-based desktop environments, so not be affected by default. Trying to convince non-rolling-release distro maintainers/packagers to backport a fix for Qt (once there is one) would in my opinion seem like the more promising approach than introducing workarounds in LibreOffice, in particular when all Qt-based applications are affected. @Eyal: Does that seem plausible to you?
(In reply to Jonathan Clark from comment #23) > Created attachment 202253 [details] > Work-in-progress qt6 patch > > As far as I can tell, this should be a one-line fix. There are comments on > those bugs suggesting it would be a significant effort though, so maybe I'm > overlooking something. This is similar to the issue you fixed in LibreOffice where styling breaks text layout. This one line fix is what LibreOffice was doing already before your fix, so it fixes the issue to some extent but it is not a complete fix. Ligatures, for example, would still be broken (some ligatures are mandatory in Arabic, لا for instance). As you noticed already, kerning would still be broken even with this fix. It is a good change to have in Qt nevertheless, since the proper fix is unlikely to happen anytime soon (judging by how long the Qt issues have been open).
Assigning to myself, since I'm working on submitting the patch to upstream. I will mark this bug fixed when it's merged. https://codereview.qt-project.org/c/qt/qtbase/+/667831
(In reply to Jonathan Clark from comment #29) > Assigning to myself, since I'm working on submitting the patch to upstream. > I will mark this bug fixed when it's merged. But it won't be fixed as an LO bug when the patch is merged - as we do not require the post-patch version as a minimum for using Qt. The time it takes between a patch of Qt and a propagation to all reasonably-modern Linux distributions is rather long. Unless we are bundling some of these libraries ourselves...?
(In reply to Jonathan Clark from comment #29) > Assigning to myself, since I'm working on submitting the patch to upstream. > I will mark this bug fixed when it's merged. > > https://codereview.qt-project.org/c/qt/qtbase/+/667831 Thanks! (In reply to Eyal Rozenberg from comment #30) > But it won't be fixed as an LO bug when the patch is merged - as we do not > require the post-patch version as a minimum for using Qt. True, the technically "more correct" status for our Bugzilla might be RESOLVED NOTOURBUG instead of RESOLVED FIXED as Jonathan is fixing it upstream, not in LibreOffice. > The time it takes > between a patch of Qt and a propagation to all reasonably-modern Linux > distributions is rather long. Unless we are bundling some of these libraries > ourselves...? No, we're not bundling Qt (or GTK), and I think we also shouldn't do so on Linux. Besides having to keep track of updating Qt to include all security fixes, etc., Qt styles/"themes" (e.g. the KDE Breeze style used by default on KDE Plasma) need to be built for the same Qt version. I.e. if we were to bundle Qt, system styles presumably couldn't be used, making LO look non-native/"odd" because it would fall back to the Qt-bundled Fusion style instead of using the system-provided Breeze one. If you think your distro should include the fix and it doesn't package the latest Qt version, I'd suggest filing a request/bug report for your distro to backport the fix, once it has been merged upstream. @Jonathan: If you consider this a fix with low risk of introducing regressions, you could mark it for backporting to release branches by adding a `Pick-to: 6.10 6.9` footer in the commit message and the corresponding bot will take care of that once it's merged to git dev.
[Changing status back to ASSIGNED, accidently changed that while checking what statuses are available...]
(In reply to Michael Weghorn from comment #31) > True, the technically "more correct" status for our Bugzilla might be > RESOLVED NOTOURBUG instead of RESOLVED FIXED as Jonathan is fixing it > upstream, not in LibreOffice. It is not, because we need to introduce a workaround for this bug in the meantime - and, I would argue, introduce a fix to both 25.2.x and 25.8.x in addition to the nightlies. > If you think your distro should include the fix and it doesn't package the > latest Qt version, I'd suggest filing a request/bug report for your distro > to backport the fix, once it has been merged upstream. That is a nice idea and everything, but it's probably not relevant to Qt5, and will probably work only for some of the distributions. Others may not do the backport or not even accept the change to begin with.
To be fair, I'll quote Walid, a user on the "LibreOffice Arabic" channel, whose opinion differs from mine: > The underline is used for hotkeys with the "ALT" keyboard button. They should > remain. However, I barely use these shortcuts (and I do not usually use Arabic > UI), but reading them in the image was horrible experience (but still > readable). I would prefere not having underlines over having the words discrete > like this. > > I do not think it deserve the investing in temporary fixing it. > > So I choose to ignore the underlines. But if they are important for others, > then it depends if volunteers are able to invest in temporary fix so, he thinks we can just wait for proper fix; but at the same time he says that it's a "horrible experience". I believe that when an aspect of the UI is "horrible", it merits even a temporary fix.
(In reply to Eyal Rozenberg from comment #34) > so, he thinks we can just wait for proper fix; but at the same time he says > that it's a "horrible experience". I believe that when an aspect of the UI > is "horrible", it merits even a temporary fix. See comment 27 for earlier thoughts. Why do people use KDE Plasma and/or the Qt variant of LO when it gives a "horrible experience" and there is GNOME and the gtk3 VCL plugin that "just work" (in that respect)? Given this has been like that "forever" (and is not a recent critical regression), I'd also tend to suggest to not introduce any workarounds, given there is an existing one that can be applied by the user: "use the gtk3 VCL plugin" (SAL_USE_VCLPLUGIN=gtk3). Introducing a workaround also has the potential to avoid the actual fix from getting applied: If we for example stop setting the accelerator in the menu item string, it won't be displayed at all even with a Qt version containing the fix. We could add a Qt runtime version check to only apply the workaround for Qt versions less than a specific version. But then, that wouldn't help for Linux distros that consider the issue critical and backport the Qt fix,...
Created attachment 202332 [details] Screenshot showing fix
(In reply to Michael Weghorn from comment #35) > Why do people use KDE Plasma and/or the Qt variant of LO when it gives a > "horrible experience" and there is GNOME and the gtk3 VCL plugin that "just > work" (in that respect)? Because that's what their OS distribution installs for them. > Given this has been like that "forever" (and is not a recent critical > regression), I'd also tend to suggest to not introduce any workarounds, > given there is an existing one that can be applied by the user: "use the > gtk3 VCL plugin" (SAL_USE_VCLPLUGIN=gtk3). The typical user encountering this does not know abour VCLs, or GTK, or setting environment variables when starting processes from the command-line.
(In reply to Jonathan Clark from comment #36) > Created attachment 202332 [details] > Screenshot showing fix How it looks with lam-alef ligature, i.e لا with one of the letters underlined?
(In reply to Khaled Hosny from comment #38) > (In reply to Jonathan Clark from comment #36) > > Created attachment 202332 [details] > > Screenshot showing fix > > How it looks with lam-alef ligature, i.e لا with one of the letters > underlined? As expected: لا أدري So it's definitely not a perfect fix, but at least it makes the problem more manageable from the app developer side.
(In reply to Michael Weghorn from comment #31) > True, the technically "more correct" status for our Bugzilla might be > RESOLVED NOTOURBUG instead of RESOLVED FIXED as Jonathan is fixing it > upstream, not in LibreOffice. The fix has been merged, so I'm closing this bug RESOLVED NOTOURBUG. > @Jonathan: If you consider this a fix with low risk of introducing > regressions, you could mark it for backporting to release branches by adding > a `Pick-to: 6.10 6.9` footer in the commit message and the corresponding bot > will take care of that once it's merged to git dev. Upstream dev elected to merge it into 6.10. It's not zero-risk. I think I'd rather leave it up to them past that. (In reply to Michael Weghorn from comment #35) > Given this has been like that "forever" (and is not a recent critical > regression), I'd also tend to suggest to not introduce any workarounds, > given there is an existing one that can be applied by the user: "use the > gtk3 VCL plugin" (SAL_USE_VCLPLUGIN=gtk3). The upshot being: affected users would apply the workaround by switching to a non-Qt distro, not by literally setting the envvar. I agree with all of this. I think we should avoid trying to carry a client code workaround.
I won't challenge the decision given that we haven't gotten this complaint from more people.
(In reply to Jonathan Clark from comment #40) > The fix has been merged, so I'm closing this bug RESOLVED NOTOURBUG. Thanks again! Setting to VERIFIED. (Haven't verified the Qt fix myself, but can verify that it's NOTOURBUG, since a native Qt menu is used.)