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
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...
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.
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.
(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).
(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.
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).
*** Bug 128470 has been marked as a duplicate of this bug. ***
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.
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.
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.
(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.
new bug for cairo issue: https://bugs.documentfoundation.org/show_bug.cgi?id=131625
*** Bug 132569 has been marked as a duplicate of this bug. ***
*** Bug 132764 has been marked as a duplicate of this bug. ***
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.
*** Bug 134482 has been marked as a duplicate of this bug. ***
Another report in https://bugs.documentfoundation.org/show_bug.cgi?id=135415.
According to comment 6, this was set to experimental -> Putting it back to Normal
(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.
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.
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.
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.
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.
*** Bug 134078 has been marked as a duplicate of this bug. ***
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/.
I can confirm that I can export to pdf from calc and writer without cairo in 7.1. However, In impress I get in some fonts letter cluttering in some pptx files. I didn't create a separate bug before i thought it could be solved together (and use cairo is a good workaround). Should I create another bug for it?
@Hans: from your message I understand that you confirm that this was fixed. What you describe doesn't sound like incomplete fix, but rather separate issue. Please search for existing bugs and if not found, report a new one, using See Also to connect to this one. Note that is may or doesn't have to be qt5 specific, so more tests you do, the better.
(In reply to Hans P. Möller from comment #26) > I can confirm that I can export to pdf from calc and writer without cairo in > 7.1. However, In impress I get in some fonts letter cluttering in some pptx > files. I didn't create a separate bug before i thought it could be solved > together (and use cairo is a good workaround). Should I create another bug > for it? This reads like it's a bug in either Qt or the Qt VCL plugin implementation and needs further analysis. As Timur wrote, please open a new report. The original export bug is fixed and from your comment I'll set it to verified.
Hello CC folks. Please see bug 136915 and write there if you reproduce with LO master, either installed or 1-file AppImage from https://libreoffice.soluzioniopen.com/daily-version/..
Jan-Marek, please see if you can backport these and 136915 to 7.0. I guess we'll have more reports otherwise. Or if not, just comment please. Thanks.
(In reply to Timur from comment #30) > Jan-Marek, please see if you can backport these and 136915 to 7.0. I guess > we'll have more reports otherwise. Or if not, just comment please. Thanks. This depends on a larger refactoring of all platforms (Linux, Win, OSX) CreateFontSubset / font code and dependencies which includes replacement of FindCmap TTF character parsinge with ParseCMAP (commit c7482bc2904401e7d975b5721ec861b8589253f9). And we still find bugs and are almost at 7.0.3 release. Technically it's not even a bugfix, but simply a missing implementation for an experimental backend, which some platforms decided to use. So no backport for 7.0 will happen from me. If someone else wants to do it (should be easy enough, as the code is old), handle the additional bugs for 7.0 too...
*** Bug 141674 has been marked as a duplicate of this bug. ***
*** Bug 143303 has been marked as a duplicate of this bug. ***
*** Bug 138917 has been marked as a duplicate of this bug. ***