Bug 125234 - qt5: exported PDf file misses embedded fonts with vcl=qt5
Summary: qt5: exported PDf file misses embedded fonts with vcl=qt5
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: All Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0
Keywords:
: 128470 132569 132764 134078 134482 (view as bug list)
Depends on:
Blocks: Qt5
  Show dependency treegraph
 
Reported: 2019-05-12 11:10 UTC by simon-eder
Modified: 2020-09-18 14:17 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
libreoffice screenshot (105.69 KB, image/jpeg)
2020-01-27 21:31 UTC, Hans P. Möller
Details
cairo bug plani libreoffice (26.93 KB, image/jpeg)
2020-02-19 13:20 UTC, Hans P. Möller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description simon-eder 2019-05-12 11:10:28 UTC
Description:
LO does not embedded fonts in a PDF file if the VCL backend qt5 is used in combination with the QPainter renderer.
Using qt5 and cairo renderer embeds the fonts.
The same happens if PDF is used as an intermediate format for printing.

Steps to Reproduce:
0, set VCL = qt5 and renderer = QPainter 
1. Open writer 
2. type some text in any font
3. export to PDF


Actual Results:
the PDF does not contain any embedded font but the error message "CreateFontSubset failed for font" instead 

Expected Results:
embed the fonts


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.3.2
Build-ID: 6.2.3-2
CPU-Threads: 2; BS: Linux 4.19; UI-Render: Standard; VCL: qt5; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
Comment 1 Jan-Marek Glogowski 2019-05-14 18:59:16 UTC
The whole font handling support in the Qt5-only variant is very basic. It'll need a lot more work to implement all the features currently missing.

Current target for 6.3 is getting all the kde5 / qt5+cairo things fixed and really usable. Maybe the default for qt5 should be changed to cairo too...
Comment 2 Jan-Marek Glogowski 2019-05-15 14:38:23 UTC
BTW: are you using the qt5 plugin out of curiosity or is there a DE, where auto-loading it would help?

That could be a valid reason to change qt5 to use the cairo drawing layer upfront when 6.2 becomes still in a few weeks (kde5 uses cairo too). qt5 would have the same "quality" as the kde5 backend, as kde5 basically just some KDE5 file / folder picker specifics.
Comment 3 simon-eder 2019-05-15 17:33:15 UTC
I'm using LxQt as DE based on QT5. 
I switched to the QT5 vcl some months back when Arch32 add a runtime dependency to the KDE libs(not installed on my system) and saving to file did crash LO. Switching to vcl=QT5 solved the problem. Everything worked fine until I wanted to do an PDF export and it failed.
Comment 4 Michael Weghorn 2019-05-15 19:05:26 UTC
(In reply to simon-eder from comment #3)
> I switched to the QT5 vcl some months back when Arch32 add a runtime
> dependency to the KDE libs(not installed on my system) and saving to file
> did crash LO.

That sounds like bug 123595 or bug 124598, which are be fixed now and I guess you'd get gtk3 by default now (not sure if this this is what you want, though).
Comment 5 simon-eder 2019-05-16 07:53:17 UTC
(In reply to Michael Weghorn from comment #4)
> That sounds like bug 123595 or bug 124598, which are be fixed now and I
> guess you'd get gtk3 by default now (not sure if this this is what you want,
> though).

Yes both bugs sound familiar, that's why I changed the vcl in the first place.
gtk3 also works for me now. 
But as I was more or less happy with the qt5 vcl for the last couple of months so  I will stick to it. But I will use cairo instead of QPainter for rendering.
Comment 6 Jan-Marek Glogowski 2019-05-16 17:00:00 UTC
So we talked about "this" on ESC today, and I'll just quote the minutes here:

* Just a reminder regarding kde5 plugin in still (Jan-Marek)
    + the qt5 plugin is currently not using cairo and it’s font handling is not
      really existing.
    + if we keep kde5, should we switch qt5 to cairo too, so that people have
      the same “quality”?
    + we get bug reports for qt5, even if its never automatically selected, like
        https://bugs.documentfoundation.org/show_bug.cgi?id=125234
    + Is that considered a problem for anyone or “if it hurts, don’t do it” ?
    + what do you prefer ? (Michael)
       + not sure – user has to select it themselves (Jmux)
          + happy to get bug reports, but reply to bugs is not helpful.
          + if switch to cairo automatically – has same quality / fixes
          + if this comes to still – and people non-automatically select it
       + years ago Kendy made effort to switch VCL from inside the app (Heiko)
          + at beginning of coding process – not clear that’s there.
          + easy to switch from one to the other to cope with issues.
          + talking wrt. Still – but won’t happen here (Jmux)
       + any downside to qt5 + cairo ? (Xisco)
          + not sure if there is any downside (Jmux)
             + plus is that Qt5 would be usable for users.
          + any objections to using Cairo for Qt5 ? (Michael)
             + can we make it more obvious it’s experimental? (Thorsten)
                + not accommodating random users who did odd things they found 				on the net.
                   + if there is a plan to improve that over time.
          + fine – how can we make this experimental ? (Jmux)
             + for help/about can write Qt5Experimental
          + had similar thing in the past for gtk3 (Miklos)
             + just ignore it unless its experimental.
		 + i.e. bail out the vcl plug if not experimental mode is on
          officecfg::Office::Common::Misc::ExperimentalMode::get()
          + any objections to making it experimental ?
          => will make it experimental.

So you'll still be able to use it, but have to enable experimental.

If some LxQt person is interested in some auto-loading, this can be revised to my original suggestion.
FWIW the gtk3_kde5 plugin is "now" also forcefully linked to KIO to prevent bug 124598, even if the library just uses the file picker through an external helper program (like Firefox does).
Comment 7 Michael Weghorn 2019-10-31 06:34:03 UTC
*** Bug 128470 has been marked as a duplicate of this bug. ***
Comment 8 Hans P. Möller 2020-01-27 21:31:40 UTC
Created attachment 157467 [details]
libreoffice screenshot

I tried with
"SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice"

and libreoffice didn't render well in LXQt, LO version 6.3.4.2 on ubuntu focal (20.04 development brach)
using only "SAL_USE_VCLPLUGIN=qt5 libreoffice" works well except the pdf problem.
Comment 9 Hans P. Möller 2020-01-27 21:31:55 UTC
I tried with
"SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice"

and libreoffice didn't render well in LXQt, LO version 6.3.4.2 on ubuntu focal (20.04 development brach)
using only "SAL_USE_VCLPLUGIN=qt5 libreoffice" works well except the pdf problem.
Comment 10 Hans P. Möller 2020-02-19 13:20:21 UTC
Created attachment 158005 [details]
cairo bug plani libreoffice

Tested in 6.4.0.3 ubuntu version
"SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice" that doesn't start and gives the error attached.

but "SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice --writer" works ok. Also calc, draw, impress, base, global, math and web works ok.
Comment 11 Jan-Marek Glogowski 2020-02-19 13:30:02 UTC
(In reply to Hans P. Möller from comment #10)
> Created attachment 158005 [details]
> cairo bug plani libreoffice
> 
> Tested in 6.4.0.3 ubuntu version
> "SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice" that doesn't
> start and gives the error attached.
> 
> but "SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice --writer"
> works ok. Also calc, draw, impress, base, global, math and web works ok.

Please open a new bug report for this. This is something that should definitely already work, as the KDE backend just uses special handling for the file picker and some KDE font settings AFAIK.

I can reproduce this with my current master (7.0) build too: qt5+cairo works with an existing profile but crashes with a fresh one here.
Comment 12 Hans P. Möller 2020-03-27 13:54:12 UTC
new bug for cairo issue:
https://bugs.documentfoundation.org/show_bug.cgi?id=131625
Comment 13 Timur 2020-05-04 20:33:29 UTC
*** Bug 132569 has been marked as a duplicate of this bug. ***
Comment 14 Timur 2020-06-18 05:47:33 UTC
*** Bug 132764 has been marked as a duplicate of this bug. ***
Comment 15 Timur 2020-06-18 05:50:15 UTC
Also Risto wrote in bug 130149 (which is different):

In FreeBSD 11.3-RELEASE-p7 (Libreoffice writer 6.4.4.2) all PDFs come out without visible text. Figures are in place and the structures of PDFs are OK except that the texts are missing.
Fonts I have tested: Times new roman, Fira Sans, Arial, Source Sans Pro, etc.
I updated from LibreOffice to 6.3.6, where the "Export as PDF..." worked as expected.
Using GTK3 as a backend instead of QT5 fixed all the problems of missing texts in PDF export.

Looks related, except version. Risto, I added you here.
Comment 16 Timur 2020-07-04 21:12:04 UTC
*** Bug 134482 has been marked as a duplicate of this bug. ***
Comment 17 Timur 2020-08-05 16:05:33 UTC
Another report in https://bugs.documentfoundation.org/show_bug.cgi?id=135415.
Comment 18 Xisco Faulí 2020-08-13 14:15:28 UTC
According to comment 6, this was set to experimental -> Putting it back to Normal
Comment 19 Jan-Marek Glogowski 2020-08-13 14:22:12 UTC
(In reply to Xisco Faulí from comment #18)
> According to comment 6, this was set to experimental -> Putting it back to
> Normal

That never happened and it's documented in some later ESC log AFAIK.

Turns out, when the VCL plugins get probed and loaded, it's too early to access the configuration data in any sensible way, so the experimental setting can't be checked. Nevertheless, the plugin is never loaded automatically.
Comment 20 Commit Notification 2020-08-15 11:19:44 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/5a888c5fd295f9b98dee9ce930e653cb63a02857

tdf#125234 Qt5 implement CreateFontSubset

It will be available in 7.1.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.
Comment 21 Commit Notification 2020-09-11 17:28:15 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/21ebde9189460318c8c04157b48ede9760a600f9

tdf#125234 Qt use glyph widths, not advance

It will be available in 7.1.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.
Comment 22 Commit Notification 2020-09-11 17:42:46 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e9b9044f7b7b44b45dd582885cad0b0a7d44f88b

tdf#125234 Qt5 set glpyh font bounding box

It will be available in 7.1.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.
Comment 23 Commit Notification 2020-09-13 20:36:14 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3c0dbea19492eecaf8e6e1cb0542a3f93c7298e3

tdf#125234 Qt5 add missing CFF font subsetting

It will be available in 7.1.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.
Comment 24 Timur 2020-09-18 14:13:56 UTC
*** Bug 134078 has been marked as a duplicate of this bug. ***
Comment 25 Timur 2020-09-18 14:16:44 UTC
Dear all in CC: 
Please try daily master from https://dev-builds.libreoffice.org/daily/master/current.html to confirm the fix, it is separate to your working LO.
Or more simple 1-file AppImage from https://libreoffice.soluzioniopen.com/daily-version/.