Created attachment 160836 [details] Libreoffice Writer displays wrong glyphs for GFS Didot Libreoffice 6.4.3.2 on Lubuntu 20.04 displays wrong glyphs for GFS Didot, but Character Map displays the right glyphs. See attachment
I've found that font and installed it, but please specify, why do you think, there is a wrong glyph. I can't see it. => NEEDINFO
(In reply to Dieter from comment #1) > I've found that font and installed it, but please specify, why do you think, > there is a wrong glyph. I can't see it. > > => NEEDINFO Hello Dieter, Thanks for your reply. I think I was misunderstood: to be specific, Writer displays the glyphs of GFS Artemisia, so that in Writer the two fonts look identical but not in the Character Map as you can see from the image I attached.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to aleslavista from comment #2) > Thanks for your reply. I think I was misunderstood: to be specific, Writer > displays the glyphs of GFS Artemisia, so that in Writer the two fonts look > identical but not in the Character Map as you can see from the image I > attached. Thanks for further explanation. Now it's more clear for me. One further question? Is it correct, that you insert the character from special character dialog and then it is displayed wrong? I also can't confirm that with. Font: GFS Didot Regular Version 1.0 Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: CL
(In reply to Dieter from comment #4) > (In reply to aleslavista from comment #2) > > Thanks for your reply. I think I was misunderstood: to be specific, Writer > > displays the glyphs of GFS Artemisia, so that in Writer the two fonts look > > identical but not in the Character Map as you can see from the image I > > attached. > > Thanks for further explanation. Now it's more clear for me. One further > question? Is it correct, that you insert the character from special > character dialog and then it is displayed wrong? I also can't confirm that > with. > > Font: GFS Didot Regular Version 1.0 > > Version: 7.0.0.0.alpha1+ (x64) > Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac > CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: > win; > Locale: en-GB (de_DE); UI: en-GB > Calc: CL You're welcome. In reply to your question, nothing changes if I paste characters from either the Special character dialog inside Writer or the Ubuntu Character Map. Glyphs still look like the ones from GFS Artemisia.
Got the font from https://fontlibrary.org/en/font/gfs-didot No problem for me, it looks the same in Special chars dialog and Writer text canvas. Please test in Safe mode, Help - Restart in safe mode and then Continue in safe mode. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: d784e711c102f204552c3c816636da01b1085f61 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 29 August 2020
Created attachment 165338 [details] Bug still occurs in Safe Mode I can confirm bug still occurs in Safe Mode. See attachment.
Just for completeness, please copy and paste here the contents of your Help - About. In 6.4 this is done by left-clicking on the text and pressing Ctrl-C. In 7.0, there is a button for copying.
(In reply to Buovjaga from comment #9) > Just for completeness, please copy and paste here the contents of your Help > - About. In 6.4 this is done by left-clicking on the text and pressing > Ctrl-C. In 7.0, there is a button for copying. Here it is: Versione: 6.4.5.2 Build ID: 1:6.4.5-0ubuntu0.20.04.1 Thread CPU: 2; SO: Linux 5.4; Resa interfaccia: predefinito; VCL: qt5; Versione locale: it-IT (it_IT.UTF-8); Lingua interfaccia: it-IT Calc: threaded
(In reply to aleslavista from comment #10) > (In reply to Buovjaga from comment #9) > > Just for completeness, please copy and paste here the contents of your Help > > - About. In 6.4 this is done by left-clicking on the text and pressing > > Ctrl-C. In 7.0, there is a button for copying. > > Here it is: > > Versione: 6.4.5.2 > Build ID: 1:6.4.5-0ubuntu0.20.04.1 > Thread CPU: 2; SO: Linux 5.4; Resa interfaccia: predefinito; VCL: qt5; > Versione locale: it-IT (it_IT.UTF-8); Lingua interfaccia: it-IT > Calc: threaded Whoa there - now this is interesting. You have "VCL: qt5", which is definitely not normal. The qt5 backend is something that is not ready to be used on its own as far as I understand. I find it amazing that Lubuntu is using it! Please try, if you can reproduce the problem by launching from the command line with: SAL_USE_VCLPLUGIN=gen libreoffice
(In reply to Buovjaga from comment #11) > (In reply to aleslavista from comment #10) > > (In reply to Buovjaga from comment #9) > > > Just for completeness, please copy and paste here the contents of your Help > > > - About. In 6.4 this is done by left-clicking on the text and pressing > > > Ctrl-C. In 7.0, there is a button for copying. > > > > Here it is: > > > > Versione: 6.4.5.2 > > Build ID: 1:6.4.5-0ubuntu0.20.04.1 > > Thread CPU: 2; SO: Linux 5.4; Resa interfaccia: predefinito; VCL: qt5; > > Versione locale: it-IT (it_IT.UTF-8); Lingua interfaccia: it-IT > > Calc: threaded > > Whoa there - now this is interesting. You have "VCL: qt5", which is > definitely not normal. The qt5 backend is something that is not ready to be > used on its own as far as I understand. I find it amazing that Lubuntu is > using it! > > Please try, if you can reproduce the problem by launching from the command > line with: > > SAL_USE_VCLPLUGIN=gen libreoffice You're right. By launching from command line with this option the bug no longer occurs. What should I do? Notify Lubuntu? How can I do so?
Created attachment 165351 [details] SAL_USE_VCLPLUGIN=gen libreoffice By typing this SAL_USE_VCLPLUGIN=gen libreoffice on command line LibreOffice starts and the bug no longer occurs.
Created attachment 165354 [details] Working OK with Qt5 in latest master Now I tested with qt5 in 6.4.0 and latest master and I don't see the problem. Maybe it is something in Lubuntu indeed. I will close this. Lubuntu bug reporting instructions: https://phab.lubuntu.me/w/bugs/
I can reproduce on Debian testing with a current master build. Fonts installed via Debian packages: fonts-gfs-artemisia, fonts-gfs-didot, fonts-gfs-didot-classic Will attach a sample file and screenshots soon. It works as expected when using qt5 with Cairo rendering, i.e. setting env variable SAL_VCL_QT5_USE_CAIRO=true in addition. As bouvjaga mentioned, using plain "qt5" VCL plugin in production is something we don't recommend, and it's never used by default unless you (or your distro) sets the SAL_USE_VCLPLUGIN=qt5 environment variable. Version: 7.1.0.0.alpha0+ Build ID: 4461d49c6cfce22c2c96185b0a1d07bfe9709268 CPU threads: 12; OS: Linux 5.7; UI render: default; VCL: qt5 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Version: 7.1.0.0.alpha0+ Build ID: 4461d49c6cfce22c2c96185b0a1d07bfe9709268 CPU threads: 12; OS: Linux 5.7; UI render: default; VCL: qt5+cairo Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Created attachment 165355 [details] Sample document
Created attachment 165356 [details] Screenshot with plain qt5 VCL plugin (NOK)
Created attachment 165357 [details] Screenshot with qt5 VCL plugin using Cairo rendering (OK)
The drawing is completely done by Qt (using QPaint::drawGlyphRun), just the layout is done in LO. I checked Qt5Graphics::DrawTextLayout, and it has the correct font (dumping pFont->family()). Then I opened a KDE font selector with a preview, like in kwrite. If you switch between GFS Artimista and GFS Didot, the preview doesn't change at all. Since the width of the glyphs is different for quite a few characters, as you can see in Michaels attached example, there should be a difference. And also the "t" is very different in both fonts: its bar aligns with height of "e" in "test" in Artimista but not Didot, and seems too small in Didot generally, so should be easy to spot. I suspect the displayed charmap program doesn't use Qt, as we know Cairo based font handling isn't affected. And since Cairo also works here, it's very likely a Qt upstream bug.
(In reply to Jan-Marek Glogowski from comment #19) > The drawing is completely done by Qt (using QPaint::drawGlyphRun), just the > layout is done in LO. I checked Qt5Graphics::DrawTextLayout, and it has the > correct font (dumping pFont->family()). > > Then I opened a KDE font selector with a preview, like in kwrite. If you > switch between GFS Artimista and GFS Didot, the preview doesn't change at > all. Since the width of the glyphs is different for quite a few characters, > as you can see in Michaels attached example, there should be a difference. > And also the "t" is very different in both fonts: its bar aligns with height > of "e" in "test" in Artimista but not Didot, and seems too small in Didot > generally, so should be easy to spot. > > I suspect the displayed charmap program doesn't use Qt, as we know Cairo > based font handling isn't affected. And since Cairo also works here, it's > very likely a Qt upstream bug. I notified Ubuntu about this bug: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1895135
BTW: an alternative fix is to use Cairo rendering, like all unix backends do, by setting SAL_VCL_QT5_USE_CAIRO=1. Today I got the info, that this is the default for LO FreeBSD.