Description: On 6.3.2.2 (tested both official RPM and Archlinux precompiled packages), the functions "Export As PDF" "Export directly as PDF" "Print.... to PDF" all generate a blank PDF with no text. Steps to Reproduce: 1. create new document 2. type a few random characters 3. export PDF Actual Results: All attempts result in a blank (no text) PDF. Drawn lines and graphic elements *seem* to work; limited testing done. The generated PDF always contains at least one line like this: % CreateFontSubset failed for font "Times New Roman" weight=5 Expected Results: Visible text Reproducible: Always User Profile Reset: Yes Additional Info: I have tried many permutations of - different fonts - different PDF format (regular / archive) - from Writer and Calc - new or existing document - deleting user profile Ideas to troubleshoot this ? **************** Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 16; OS: Linux 5.3; UI render: default; VCL: qt5; Locale: en-CA (en_CA.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 155403 [details] sample blank PDF
>% CreateFontSubset failed for font "Times New Roman" weight=5 Do you use Times New Roman font on Linux? And in the your document too? Can you attach your ODT document with some text that you tried export to PDF?
Created attachment 155410 [details] sample test file with 6 fonts
> Do you use Times New Roman font on Linux? My linux system font is "DejaVu Sans"; I had tried a document with that font and still the same result. Attached is a document with 6 different fonts; the PDF contains a "% CreateFontSubset failed" line for each of those fonts.
don't repro in Версия: 6.4.0.0.alpha1+ (x64) ID сборки: 546e6c359e96a2e7f5aab7c158c7e843be6c8957 Потоков ЦП: 4; ОС:Windows 10.0 Build 17763; Отрисовка ИП: GL; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded nor in Версия: 6.3.3.2 (x64) ID сборки: a64200df03143b798afd1ec74a12ab50359878ed Потоков ЦП: 4; ОС:Windows 10.0; Отрисовка ИП: по умолчанию; VCL: win; Локаль: ru-RU (ru_RU); Язык интерфейса: ru-RU Calc: threaded only Linux? or only vcl:qt problem?
I can reproduce with Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: qt5; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded but not with Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: nl-BE (en_US.UTF-8); UI-Language: en-US Calc: threaded
Please note that the plain "qt5" VCL plugin using Qt rendering is experimental and not recommended for production use as of now, which is also why it's never chosen by default. Do you have environment variable SAL_USE_VCLPLUGIN=qt5 set explicitly? This problem does not occur with Cairo rendering, i.e. if you set SAL_VCL_QT5_USE_CAIRO=true in addition, or if you use the kf5 VCL plugin, which is selected by default on LXQt or KDE Plasma. In fact, there is already a bug report for this: bug 125234 Reproducible with Version: 6.4.0.0.alpha1+ Build ID: bfd6beaa8e836c739dcc2af67ebd634f03cb2060 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: qt5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Does not happen with Version: 6.4.0.0.alpha1+ Build ID: bfd6beaa8e836c739dcc2af67ebd634f03cb2060 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: qt5+cairo; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded nor Version: 6.4.0.0.alpha1+ Build ID: bfd6beaa8e836c739dcc2af67ebd634f03cb2060 CPU threads: 4; OS: Linux 5.2; UI render: default; VCL: kf5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded *** This bug has been marked as a duplicate of bug 125234 ***
Thanks for the testing and replies. Apologies for the dupe, I wasn't able to find that other report the first time I searched. I only recently found out about SAL_USE_VCLPLUGIN, and indeed for some reason it's set to qt5 on my system once inside lxqt, due to the /usr/bin/startlxde script. Explicitly setting SAL_USE_VCLPLUGIN=gtk3 solves my initial problem, although the UI looks weird. Again, thanks and sorry for the duplicate !
Thanks for the update. (In reply to fenugrec from comment #8) > Thanks for the testing and replies. > Apologies for the dupe, I wasn't able to find that other report the first > time I searched. No problem. :-) > I only recently found out about SAL_USE_VCLPLUGIN, and indeed for some > reason it's set to qt5 on my system once inside lxqt, due to the > /usr/bin/startlxde script. > > Explicitly setting SAL_USE_VCLPLUGIN=gtk3 solves my initial problem, > although the UI looks weird. You can also try SAL_USE_VCLPLUGIN=kf5, which would be like the default if nothing had been set explicitly. (Or as mentioned, you can set SAL_VCL_QT5_USE_CAIRO=true in combination with SAL_USE_VCLPLUGIN=qt5, which should most probably be fine as well, though it's nothing that is currently used anywhere by default; kf5 is mostly qt5+cairo plus native kf5 file dialogs).