I found a simple enough workaround for the graphics problem: maximize/unmaximize the window. The graphics scramble occurs immediately after loading a file, and only with the USE_CAIRO flag. Maximizing (or unmaximizing if the window started maximized) clears it up
The Terminal command recommended by ailtonbsj worked for me (after closing and reopening LibreOffice); many thanks. Having done this step, I printed a document successfully.
Side-effect: the icons and ‘skin’ of LibreOffice change as a result of this action (presumably, this is because the qt5 theme within LibreOffice is lost – in my case, this resulted in the graphics becoming larger and a bit clearer).
This raises a further question: will libreoffice-qt5 remain removed upon installing further system upgrades within 20.04 LTS?
Hello, just a message to mention that LibreOffice 7.0.3 from the official website (https://www.libreoffice.org/download/download/) works all fine on Lubuntu 20.04 LTS. No graphic bugs and pdf export and printing is fine. (After download you need to unzip the archive and install all the .deb package files with something like “apt install ./*.deb”…).
Can you confirm (see Help » About LibreOffice) that you’re using the qt5 VCL? And can you confirm you have 7.0.3.1? Also, could you check the latest daily version of Lubuntu (which has 7.0.3 in it) and see if you have the same problems with it that you did on the older version?
I will say that I cannot confirm your experience. I still get a PDF with no text. I have a feeling the reason it might have worked for you is you had modified some other things. My guess is your VCL is not the qt5 one.
I ran a test on this issue today on Lubuntu Hirsute 21.04 daily 11.12.2020 which has the LibreOffice 7.03.1 in it and experienced no problems with export to pdf. It has the qt5 VCL as default.
Holy crap, @leok, that’s amazing news!!! Ir’s a little bizarre that the one I downloaded yesterday didn’t work but I see it wasn’t using the qt5 +cairo VCL, so that might have been the key.
Were there other issues besides the PDF export that we should check on?
Yes - one issue was that LibreOffice only opens files on Samba shares as “read-only” i.e open a copy. I filed a bug back in April - I will check again (in the AM) to see if this is still the case.
I was thinking more about issues that related specifically to the VCL but that one is very interesting. I would suggest triaging that upstream, especially if you get the log entries with other distros. What is going on here is that the AppArmor profile is in complain mode, which is to say it’s logging a violation of policy, but it’s not denying it (which is why it says apparmor="ALLOWED". That should be a non-blocker. You can confirm this with sudo aa-disable /etc/apparmor.d/usr.lib.libreoffice.program.soffice.bin and then trying again (turn it back on with sudo aa-complain).
Did some testing on this Samba issue today with the latest builds Hirsute 21.04 for Lubuntu and Xubuntu.
Regarding Lubuntu if I ran aa-disable … (as in above post ) the file did not open at all. Turning it back on and file opened with the same results. I have added further comments to the bug report and of particular interest is that this is not a Lubuntu issue.
Opening Samba share files in Xubuntu gives the same results i.e you can only open a copy and are unable to edit the original file. All other apps i.e, featherpad,mousepad etc, can open Samba files in edit mode.
As far as I can determine this has something to do with how LibreOffice assigns permissions.
It would be helpful if someone else could test this and confirm the bug.
Further testing on Ubuntu and Ubuntu Mate with the 13.12.2020 builds - surprised to see that LibreOffice could open the Samba files in edit mode. Looks like I need to dig deeper.