Created attachment 182783 [details] Text box with autofit text (master slide of an empty presentation) I'm using: Version: 7.4.1.2 / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: qt5 (qfont+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US ... on Lubuntu 20.04 (LXQt desktop environment). When I open LO Impress and view the Master slide, I get the attached result. I can also get the same result by entering text in the textboxes on the empty slide of a new presentation, then right-clicking the text box and enabling "AutoFit text". Not seeing this behavior with 7.3.6.2 on the same machine.
Lubuntu packagers insist on using qt5 even though it is not recommended. Can you check with the advice from https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1895216 Running with SAL_VCL_QT5_USE_CAIRO=1 libreoffice from the command line, if it makes a difference?
(In reply to Buovjaga from comment #1) > Lubuntu packagers insist on using qt5 even though it is not recommended. Can > you check with the advice from > https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1895216 > > Running with > > SAL_VCL_QT5_USE_CAIRO=1 libreoffice > > from the command line, if it makes a difference? Yes, the letters don't overlap, but shapes look super weird :-)
(In reply to Eyal Rozenberg from comment #2) > (In reply to Buovjaga from comment #1) > > Lubuntu packagers insist on using qt5 even though it is not recommended. Can > > you check with the advice from > > https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1895216 > > > > Running with > > > > SAL_VCL_QT5_USE_CAIRO=1 libreoffice > > > > from the command line, if it makes a difference? > > Yes, the letters don't overlap, but shapes look super weird :-) Michael: thoughts?
Created attachment 185745 [details] A slide without explicitly enabling Cairo
Created attachment 185746 [details] A slide with explicitly enabled Cairo Both of these were rendered by: Version: 7.5.1.2 (X86_64) / LibreOffice Community Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129 CPU threads: 4; OS: Linux 5.4; UI render: default; Locale: en-GB (en_GB.UTF-8); UI: en-US Without Cairo it's: VCL: qt5 (qfont+xcb) And with Cairo it's: VCL: qt5 (cairo+xcb)
(In reply to Buovjaga from comment #1) > Lubuntu packagers insist on using qt5 even though it is not recommended. Also... getting this with a version of LO I downloaded from the website. I mean, initially, it might have been whatever Lubuntu packaged, now it's LO's DEBs.
(In reply to Eyal Rozenberg from comment #6) > (In reply to Buovjaga from comment #1) > > Lubuntu packagers insist on using qt5 even though it is not recommended. > > Also... getting this with a version of LO I downloaded from the website. I > mean, initially, it might have been whatever Lubuntu packaged, now it's LO's > DEBs. and what if you run with SAL_USE_VCLPLUGIN=kf5 and check that VCL is kf5 in About dialog?
Created attachment 185747 [details] A slide with explicitly enabled Cairo
(In reply to Buovjaga from comment #7) > and what if you run with > > SAL_USE_VCLPLUGIN=kf5 > > and check that VCL is kf5 in About dialog? I get: CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) with the text not overlapping but the shape drawn weirdly. But - perhaps the shape thing merits its own bug?
(In reply to Eyal Rozenberg from comment #6) > (In reply to Buovjaga from comment #1) > > Lubuntu packagers insist on using qt5 even though it is not recommended. > > Also... getting this with a version of LO I downloaded from the website. I > mean, initially, it might have been whatever Lubuntu packaged, now it's LO's > DEBs. If (which is what I'd guess to be the case) Lubuntu sets the SAL_USE_VCLPLUGIN=qt5 environment variable for the session, that affects all LO installations, not just the Lubuntu-packaged one. You can check with `env | grep SAL` to see whether this variable is set (and `grep -r SAL_USE_VCLPLUGIN /etc/X11/Xsession*` might show where this is set, if it uses the "traditional" mechanism; there may be other ways by now to achieve the same e.g. if systemd's session management is used). As mentioned in the bug report Ilmari mentioned in comment 1, I'd strongly recommend setting SAL_VCL_QT5_USE_CAIRO=1 as well if using qt5; otherwise this results in the (known to be experimental and not meant to be used in production) qfont rendering path being used. (In reply to Eyal Rozenberg from comment #9) > I get: > > CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) > > with the text not overlapping but the shape drawn weirdly. But - perhaps the > shape thing merits its own bug? Yes, that sounds like a different issue that should be handled separately. Please also attach a sample presentation there that can be used to reproduce. (I only see screenshots here so far.) If this happens only with kf5 and e.g. not gtk3, feel free to set that as blocking for the kf5 meta bug tdf#102495.
(In reply to Michael Weghorn from comment #10) > (In reply to Eyal Rozenberg from comment #6) > > (In reply to Buovjaga from comment #1) > > > Lubuntu packagers insist on using qt5 even though it is not recommended. > > > > Also... getting this with a version of LO I downloaded from the website. I > > mean, initially, it might have been whatever Lubuntu packaged, now it's LO's > > DEBs. > > If (which is what I'd guess to be the case) Lubuntu sets the > SAL_USE_VCLPLUGIN=qt5 environment variable for the session, that affects all > LO installations, not just the Lubuntu-packaged one. You can check with `env > | grep SAL` to see whether this variable is set (and `grep -r > SAL_USE_VCLPLUGIN /etc/X11/Xsession*` might show where this is set, if it > uses the "traditional" mechanism; there may be other ways by now to achieve > the same e.g. if systemd's session management is used). Looking at https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1895216 again, it actually says: > /etc/xdg/xdg-Lubuntu/lxqt/session.conf sets SAL_USE_VCLPLUGIN=qt5 as environment variable
*** Bug 153679 has been marked as a duplicate of this bug. ***
Can be seen as far back as 6.3: Version: 6.3.6.2 Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 185767 [details] test ODP comparing autofit vs not autofit
(In reply to Buovjaga from comment #1) > Lubuntu packagers insist on using qt5 even though it is not recommended. Sorry for asking, but - shouldn't the font rendering problem just get fixed, making qt5 less-not-recommended? Unless we plan on discarding qt5 for some reason.
(In reply to Eyal Rozenberg from comment #15) > (In reply to Buovjaga from comment #1) > > Lubuntu packagers insist on using qt5 even though it is not recommended. > > Sorry for asking, but - shouldn't the font rendering problem just get fixed, > making qt5 less-not-recommended? Unless we plan on discarding qt5 for some > reason. Sure, but with this approach to packaging, Lubuntu devs should have committed the developer resources to bring the qt5 VCL plugin to a production ready state.
(In reply to Buovjaga from comment #16) > Sure, but with this approach to packaging, Lubuntu devs should have > committed the developer resources to bring the qt5 VCL plugin to a > production ready state. That's fair. I'm guessing their consideration is: "We've switched our desktop environment from gtk to qt, so we'll make all apps switch if possible" - without making sure or investing effort in ensuring that's possible. But - is this properly an LO bug, or is it an issue with the Qt libraries themselves?
(In reply to Eyal Rozenberg from comment #15) > Sorry for asking, but - shouldn't the font rendering problem just get fixed, > making qt5 less-not-recommended? Unless we plan on discarding qt5 for some > reason. We should differentiate between 2 things here: 1) The qt5 VCL plugin with Cairo rendering. 2) The qt5 VCL plugin with QFont-based rendering. From my perspective, we can stop calling 1) not-recommended (should basically work as well as the kf5 VCL plugin), but 2) is experimental and currently not actively being worked on. (In reply to Eyal Rozenberg from comment #17) > That's fair. I'm guessing their consideration is: "We've switched our > desktop environment from gtk to qt, so we'll make all apps switch if > possible" - without making sure or investing effort in ensuring that's > possible. Technically, there would be no problem in switching to qt5 with Cairo rendering. The issue is that by setting SAL_USE_VCLPLUGIN=qt5 but not SAL_VCL_QT5_USE_CAIRO=1, they implicitly opted in for QFont-based rendering, which is known to be suboptimal. Our assumption back then was that if people manually set custom environment variables, they should know what they're doing. My suggestion for now would still be that Lubuntu packaging should set SAL_VCL_QT5_USE_CAIRO=1 in addition to provide their users a better experience. But so far, nothing has happened in https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1895216 . What we can still consider is switching the default from 2) to 1), i.e. people that only set SAL_USE_VCLPLUGIN=qt5 get the more mature Cairo rendering by default. And then introduce some new environment variable (maybe sth like SAL_VCL_QT5_USE_QFONT_RENDERING) to explicitly switch to the experimental QFont rendering. > But - is this properly an LO bug, or is it an issue with the Qt libraries > themselves? Hard to tell without looking into this in detail, but I'd initially assume that it's a LO bug until anybody looks into it and claims otherwise. But then, I'm quite sure that solving this one issue will still leave enough others to not recommend using QFont rendering in production.
(In reply to Michael Weghorn from comment #18) > (In reply to Eyal Rozenberg from comment #15) > What we can still consider is switching the default from 2) to 1), i.e. > people that only set SAL_USE_VCLPLUGIN=qt5 get the more mature Cairo > rendering by default. And then introduce some new environment variable > (maybe sth like SAL_VCL_QT5_USE_QFONT_RENDERING) to explicitly switch to the > experimental QFont rendering. I'm very much in favor of that: The default should be the more robustly-implemented alternative. Unless there's some strong argument to the contrary I'm not aware of?
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f9b16330f13d3ad43de6de026206577bfa1ac85d tdf#151273, tdf#151925: Don’t use QFont text layout by default It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/14fe410e0ab90e95141613b77de48063f518d9bb tdf#151273, tdf#151925: Don’t use QFont text layout by default It will be available in 7.6.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/eb9b5ec7620f236243636cd94f517fc80006b95a tdf#151273, tdf#151925: Don’t use QFont text layout by default It will be available in 7.5.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.