As far as I can remember, there was some connection of such an issue to installed fonts on the system and the native Qt rendering.

Can you try what happens when you force Cairo rendering instead of the Qt native rendering? You can do so by starting LibreOffice with

SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 ./instdir/program/soffice --writer


Also, are there any font-related warnings when you start via command line?

(In reply to Michael Weghorn from comment #1)
> As far as I can remember, there was some connection of such an issue to
> installed fonts on the system and the native Qt rendering.
> 
> Can you try what happens when you force Cairo rendering instead of the Qt
> native rendering? You can do so by starting LibreOffice with
> 
> SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 ./instdir/program/soffice
> --writer
> 
> 
> Also, are there any font-related warnings when you start via command line?

that worked!! now I see  VCL: qt5+cairo;

I don't see any fonts warning, actually I don't see nothing in terminal, is there a way to run it in verbose mode?

(In reply to Hans P. Möller from comment #2)
> I don't see any fonts warning, actually I don't see nothing in terminal, is
> there a way to run it in verbose mode?

As far as I can remember, those warnings were shown "by default", at least in a debug build. You can set the environment variable SAL_LOG=INFO, which will generate a lot of output (it's also possibly to specify more exactly what exactly to increase the log level for), but I think this also only applies for debug builds.

The best would probably to download a debug build and try with that. Daily builds are available at [1] and [2] describes how you can use them without installing.

[1] https://dev-builds.libreoffice.org/daily/
[2] https://wiki.documentfoundation.org/Installing_in_parallel/Linux

*** Bug 123453 has been marked as a duplicate of this bug. ***

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/9ad2443bfe127dfe8e8940461119d36872b6c186%5E%21

tdf#123072 Qt5 don't register unknown PSP fonts

It will be available in 6.3.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.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/3519325b7d1fa80220f52b74bce3dd75eb220038%5E%21

tdf#123072 Qt5 just use data from QFontDatabase

It will be available in 6.3.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.

So these patches should cut down startup time for qt5 a lot. It's still not as fast as Cairo, but very much better here with all these Noto font variants installed for testing.

And these kind of bugs are the reason the qt5 VCL plugin (read it as the QPainter rendering path) is never selected automatically: the rendering code is still too buggy, especially the font handling. As you know you can switch the qt5 plugin to use Cairo. KDE5 just hard-codes Cairo, as it's just a few additional LOC to implement some KF5 specific stuff on top of qt5.

Still I'm happy if people test it, but it (QPainter rendering) is - almost literally - a one person free time show. This plugin gets all the general fixes through the kde5 one, but this currently explicitly excludes the whole rendering. And IMHO there are still too many other bugs in the KDE5 meta, which IMHO still makes it experimental, but it gets much better, as many more people are interested in fixing it :-)

There will be some discussion in ESC, if the kde5 plugin should be selected at all when 6.2 becomes LO still (start of June when 6.3.0 will be out). We wanted people to test it without too much hassle, so it's currently available and not experimental. Maybe that'll change, but we have three more months to fix 6.2 enough.

Just checked: week 24 is the "Hard code freeze" and the release in week 27, so that's three months - given or taken a few days.

I've checked for

Version: 6.3.0.0.alpha0+
Build ID: 5e30823e8a25066aa7bbaa801583dbfa7db55a72
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: qt5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-03-31_17:29:00
Locale: ru-RU (ru_RU.UTF-8); UI-Language: en-US
Calc: threaded

Writer, Calc started while 1-3 sec.

Sorry I didn't had time before to test. I'm using the stock version of development ubuntu 20.04, which is 6.3.4.2, and vcl=qt5 works awesome.
Thanks!