Created attachment 1096359 [details] dialog Description of problem: The text is unreadable. See attachment. Version-Release number of selected component (if applicable): How reproducible: always (although not all dialogs, I have mostly seen it with calc) Name : libreoffice-calc Epoch : 1 Version : 5.0.3.2 Release : 4.fc23 Architecture: x86_64 Install Date: Tue 10 Nov 2015 10:42:24 AM CST Group : Applications/Productivity Size : 29978385 License : (MPLv1.1 or LGPLv3+) and LGPLv3 and LGPLv2+ and BSD and (MPLv1.1 or GPLv2 or LGPLv2 or Netscape) and Public Domain and ASL 2.0 and Artistic and MPLv2.0 and CC0 Signature : RSA/SHA256, Sat 07 Nov 2015 07:13:35 PM CST, Key ID 32474cf834ec9cba Source RPM : libreoffice-5.0.3.2-4.fc23.src.rpm Build Date : Thu 05 Nov 2015 02:28:23 PM CST Build Host : buildhw-06.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.libreoffice.org/ Summary : LibreOffice Spreadsheet Application
Which dialog is the screen shot of ? The "Do you want to save" dialog is definitely rock solid for me with no corruption.
Created attachment 1096743 [details] license information I don't remember what dialog it was. however, the issue can be reproduced simply by displaying license information (help->license information). This one is from oowriter (te same issue in oocalc).
Created attachment 1096745 [details] partial corruption sometimes only part of the dialog displays with corrupted fonts. The following happens every time I try to copy-paste text(with newlines and tabs/spaces) into oocalc.
*** Bug 1287411 has been marked as a duplicate of this bug. ***
gtk3 backend is unaffected, only the gtk2 one. Double checking with old versions of libreoffice 4.0.0 those are also affected if run on fedora 23, so seems that whatever the problem is is, its not a regression on our side. Either it was "always wrong, but worked", or some other component has broken. My money is on some XRendr problem.
we're drawing the text with cairo, interestingly if I add an additional debugging draw + clear of a pixel via cairo_fill to that xlib surface before drawing the text, then it renders perfectly fine. I'll try and extract a standalone demo unless the rings a bell with anyone.
can't seem to create a standalone example. I can tell that if I build cairo with --enable-xlib-xrender=no then it also works fine, so the problem is in that direction
I'll just bodge this to work for now. Still unsure what the core reason actually is.
libreoffice-5.0.4.2-3.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-98c92e275f
libreoffice-5.0.4.2-3.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-98c92e275f
libreoffice-5.0.4.2-3.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1293023 has been marked as a duplicate of this bug. ***