Download it now!
Bug 125925 - Qt5 VCL UI Fonts are small
Summary: Qt5 VCL UI Fonts are small
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.3.0.0.beta1+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Qt5
  Show dependency treegraph
 
Reported: 2019-06-14 16:10 UTC by Ongun Kanat
Modified: 2020-09-10 11:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (56.56 KB, image/png)
2019-06-14 16:10 UTC, Ongun Kanat
Details
Screenshot with larger font (71.55 KB, image/png)
2019-06-15 22:09 UTC, Michael Weghorn
Details
The Welcome screen. On the left native Qt 5 app Kid3-Qt. (628.33 KB, image/png)
2019-06-15 22:35 UTC, Ongun Kanat
Details
Writer window. Comboboxes got bigger but fonts stay small. (593.43 KB, image/png)
2019-06-15 22:36 UTC, Ongun Kanat
Details
Cairo back-end crash. (131.22 KB, image/png)
2019-06-15 22:55 UTC, Ongun Kanat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ongun Kanat 2019-06-14 16:10:55 UTC
Created attachment 152194 [details]
Screenshot

LibreOffice 6.3 beta uses smaller fonts than configured Qt style. Only the menu is displayed correctly.

I configured fonts via KDE configuration.


Distro: Arch Linux
LibreOffice version: 6.3.0.0 beta1 AppImage
Qt: 5.12.3
Comment 1 Michael Weghorn 2019-06-15 22:09:48 UTC
Created attachment 152215 [details]
Screenshot with larger font

I cannot reproduce with

Version: 6.4.0.0.alpha0+
Build ID: 77a3c443d35c7d966217f02ea9189cb1819c7828
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

For testing, I set the "General" font size to 48 in Plasma's system settings and as the attached screenshot shows, various fonts got larger, also e.g. for the context menu. This is on Debian testing (QT 5.11.3).

Can you try again with that setting and if the problem is still there, be more explicit where the font does not change as expected?

Also, please paste the version information from "Help" -> "About LibreOffice".
Comment 2 Jan-Marek Glogowski 2019-06-15 22:20:56 UTC
This is a known problem of the qt5 QPainter backend. There are currently some mix ups between Qt's system independent font point size and the native font size. As a result everything looks a bit smaller with qt5.
Comment 3 Michael Weghorn 2019-06-15 22:30:18 UTC
(In reply to Jan-Marek Glogowski from comment #2)
> This is a known problem of the qt5 QPainter backend. There are currently
> some mix ups between Qt's system independent font point size and the native
> font size. As a result everything looks a bit smaller with qt5.

And please note that the plain qt5 VCL plugin (as opposed to the kde5 one) is experimental, and you can switch to Cairo rendering as described in the meta bug 125943.
Comment 4 Ongun Kanat 2019-06-15 22:32:31 UTC
The version info is:

Version: 6.3.0.0.beta1
Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
CPU threads: 8; OS: Linux 5.1; UI render: default; VCL: qt5; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

The problem persist. However UI components like comboboxes got bigger. I'll upload a screenshot of that. Fonts are still small. Maybe AppImage specific? I cannot compile LibreOffice since it takes forever. If you have binaries that compiled with up to date system libraries (at least QT 5.12.3), I can test that version.
Comment 5 Ongun Kanat 2019-06-15 22:35:47 UTC
Created attachment 152217 [details]
The Welcome screen. On the left native Qt 5 app Kid3-Qt.

It seems like Qpainter backend doesn't honor font settings.
Comment 6 Ongun Kanat 2019-06-15 22:36:58 UTC
Created attachment 152218 [details]
Writer window. Comboboxes got bigger but fonts stay small.
Comment 7 Michael Weghorn 2019-06-15 22:44:43 UTC
Since Jan-Marek confirmed, let's set status back to NEW and keep this blocking for the qt5 QPainter meta bug, not the KDE5 one...
Comment 8 Michael Weghorn 2019-06-15 22:49:13 UTC
(In reply to Ongun Kanat from comment #4)
> The version info is:
> 
> Version: 6.3.0.0.beta1
> Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b
> CPU threads: 8; OS: Linux 5.1; UI render: default; VCL: qt5; 
> Locale: en-US (en_US.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> The problem persist. However UI components like comboboxes got bigger. I'll
> upload a screenshot of that. Fonts are still small. Maybe AppImage specific?
> I cannot compile LibreOffice since it takes forever. If you have binaries
> that compiled with up to date system libraries (at least QT 5.12.3), I can
> test that version.

Bug 125926 comment 4 describes where you can get current development versions.
Given Jan-Marek's comment 2 this is probably not AppImage-specific, though.
Please note that I used the kde5 VCL plugin for testing (which uses the Cairo rendering path), while you seem to be using the experimental qt5 one (QPainter rendering path).
[And please clarify in bug 125926 what exact version you're using there.]
Comment 9 Ongun Kanat 2019-06-15 22:55:53 UTC
Created attachment 152219 [details]
Cairo back-end crash.

(In reply to Michael Weghorn from comment #3)
> (In reply to Jan-Marek Glogowski from comment #2)
> > This is a known problem of the qt5 QPainter backend. There are currently
> > some mix ups between Qt's system independent font point size and the native
> > font size. As a result everything looks a bit smaller with qt5.
> 
> And please note that the plain qt5 VCL plugin (as opposed to the kde5 one)
> is experimental, and you can switch to Cairo rendering as described in the
> meta bug 125943.

I am aware of KDE5 and Cairo back-end. I am just testing out stuff to give feedback and see how much improvement has been done.

The current beta1 AppImage outright crashes and shows crash report screen with Cairo. I am uploading a screenshot for it also, since the crash screen also have smaller fonts than standard Qt font.

The problem is that KDE5 VCL is not usable either. I use GTK 3 for stable use. Heck, I would go back GTK2 for daily stability if it wasn't deprecated. It was much more snappy than current GTK3 VCL and it could handle huge list of Noto fonts and weird fonts better than GTK3.
Comment 10 Michael Weghorn 2019-06-15 23:05:09 UTC
(In reply to Ongun Kanat from comment #9)
> I am aware of KDE5 and Cairo back-end. I am just testing out stuff to give
> feedback and see how much improvement has been done.

Nice. Thanks! :)

> 
> The current beta1 AppImage outright crashes and shows crash report screen
> with Cairo. I am uploading a screenshot for it also, since the crash screen
> also have smaller fonts than standard Qt font.

I wasn't even aware TDF provides AppImages as well. I quickly tried and AppImage of 6.3.0.0.beta1 starts fine for me with both qt5 and kde5 for Cairo rendering path.

> 
> The problem is that KDE5 VCL is not usable either. I use GTK 3 for stable
> use. Heck, I would go back GTK2 for daily stability if it wasn't deprecated.
> It was much more snappy than current GTK3 VCL and it could handle huge list
> of Noto fonts and weird fonts better than GTK3.

Anything specific that makes KDE5 VCL unusable? Are there already existing bug reports for this? A lot of things have been fixed for the development version and backported for 6.2.5 recently.
Comment 11 Ongun Kanat 2019-06-16 00:49:11 UTC
(In reply to Michael Weghorn from comment #10)

> I wasn't even aware TDF provides AppImages as well. I quickly tried and
> AppImage of 6.3.0.0.beta1 starts fine for me with both qt5 and kde5 for
> Cairo rendering path.
> 

It might be a new thing caused by the updates to the libraries. Qt and freetype had changes in the API and behavior. Debian Testing doesn't have them. It needs to be tested in a distro with more recent packages. As I said in bug 125926 openSUSE Tumbleweed is a good candidate.

Sorry I cannot test the daily .deb/.rpm builts because of the reasons in Bug 125926 comment 5 .

> Anything specific that makes KDE5 VCL unusable? Are there already existing
> bug reports for this? A lot of things have been fixed for the development
> version and backported for 6.2.5 recently.

It is generally papercuts here and there. 

* The UI generally feels slower than GTK. It takes 2 - 3 seconds to initialize a new document after clicking New {Writer, Calc, Impress} document button.

* GTK version is still a lot slower than commercial software. Opening my old internship report (.docx mandated style by University) with its huge PNG diagrams takes seconds in GTK and scrolling to those pages is a nightmare; this effect is 2 times worse in KDE5 VCL.

* Right click and the notebook bar context menus in 6.2.4 (the official distro supplied package) are slow, highlighting and showing submenu happens after a significant delay 1 - 2 seconds. It is like a milder version of bug 125927.

* UI is non-native and it shows here and there like bug 125926. The UI controls like combo boxes are obviously non native. Clicking on them launches a sub dialog like menu rendered in GTK. They behave really differently than other Qt/KDE apps. My touchpad has horizontal scroll and unintentionally triggering it causes non-native combobox dialogs scroll right and hide the labels inside which is extremely annoying. That's why I also try Qt5 port. Unless LibreOffice uses native Qt drawing and components it will always feel slightly out of place. Thankfully KDE guys did a great job in Breeze GTK theme, it has the out of place feeling of GTK but look-wise the results are really acceptable.

I don't write these to rant or blame somebody. You wanted specific details so I put some examples of my experiences. I don't/can't use LibreOffice to do serious work. However I use it now and then to create simple documents. If I use KDE5 VCL it quickly turns into a fight between me and the UI. It gets in the way. With GTK it is at least acceptable.

Also as a software developer I can understand that creating bug reports like "LO is slow" will not solve anything. It is a decade long process to constant refactor and optimization and as any libre software project LO lacks resources. If I can get something concrete and worth reporting, I will. Otherwise it is up to the developers and their taste and availability.
Comment 12 Michael Weghorn 2019-06-17 06:53:25 UTC
(In reply to Ongun Kanat from comment #11)
> It is generally papercuts here and there.
> [...]
> I don't write these to rant or blame somebody. You wanted specific details
> so I put some examples of my experiences. I don't/can't use LibreOffice to
> do serious work. However I use it now and then to create simple documents.
> If I use KDE5 VCL it quickly turns into a fight between me and the UI. It
> gets in the way. With GTK it is at least acceptable.

Thanks for mentioning some of those. Feel free to retest from time to time. Main focus so far was getting functional bugs solved for the "kde5" VCL plugin.

> * UI is non-native and it shows here and there like bug 125926. The UI
> controls like combo boxes are obviously non native. Clicking on them
> launches a sub dialog like menu rendered in GTK. They behave really
> differently than other Qt/KDE apps. My touchpad has horizontal scroll and
> unintentionally triggering it causes non-native combobox dialogs scroll
> right and hide the labels inside which is extremely annoying.

This might be bug 125201 which was solved recently and will no longer be present in 6.3.
Comment 13 Ongun Kanat 2019-10-28 23:25:46 UTC
(In reply to Michael Weghorn from comment #12)

> > * UI is non-native and it shows here and there like bug 125926. The UI
> > controls like combo boxes are obviously non native. Clicking on them
> > launches a sub dialog like menu rendered in GTK. They behave really
> > differently than other Qt/KDE apps. My touchpad has horizontal scroll and
> > unintentionally triggering it causes non-native combobox dialogs scroll
> > right and hide the labels inside which is extremely annoying.
> 
> This might be bug 125201 which was solved recently and will no longer be
> present in 6.3.

No that's a completely different bug. The problem is LO doesn't use Qt-native components  and try to invent its own. It will always be non-native looking for us KDE users as this approach continued to be used but there's not much to do without redesigning LO from scratch as far as I understand from VCL related wiki pages and bug reports etc.


This bug persists on the latest build of LO and the screenshots are the same:

Version: 6.4.0.0.alpha1+
Build ID: e6109939b448f070848bfcf11ac013e05f71767a
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-10-27_22:29:11
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 14 Michael Weghorn 2019-10-29 07:01:01 UTC
(In reply to Ongun Kanat from comment #13)
> > This might be bug 125201 which was solved recently and will no longer be
> > present in 6.3.
> 
> No that's a completely different bug. The problem is LO doesn't use
> Qt-native components  and try to invent its own. It will always be
> non-native looking for us KDE users as this approach continued to be used
> but there's not much to do without redesigning LO from scratch as far as I
> understand from VCL related wiki pages and bug reports etc.

As far as I can tell, this doesn't require LO to be redesigned from scratch, but mainly "welding" needs to be implemented for qt5 as well, as has been done for gtk3, which allows native gtk3 widgets to be used now.
So that should be doable, but is probably quite some work.