Description: Slide created from Alizarin template looks ugly with Skia Steps to Reproduce: 0. Make sure Skia is enabled 1. Create a new presentation from Alizarin template 2. Looks at slide (see a screenshot in attach) Actual Results: slide looks ugly with Skia Expected Results: slide looks good with Skia Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
Created attachment 163831 [details] A screenshot with Skia enabled
No repro Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Hi Roman, Do you reproduce it with a clean profile ?
(In reply to Xisco Faulí from comment #3) > Hi Roman, > Do you reproduce it with a clean profile ? Yep
(In reply to Roman Kuznetsov from comment #4) > (In reply to Xisco Faulí from comment #3) > > Hi Roman, > > Do you reproduce it with a clean profile ? > > Yep And with Raster? [Force Skia Software mode?]
(In reply to Telesto from comment #5) > (In reply to Roman Kuznetsov from comment #4) > > (In reply to Xisco Faulí from comment #3) > > > Hi Roman, > > > Do you reproduce it with a clean profile ? > > > > Yep > > And with Raster? [Force Skia Software mode?] Yes, and with Skia/Raster too, I checked
To make it even more clear, this happens also with GDI; should have asked the first time? Maybe - thinking out loud - some kind of font corruption or font replacement issue? Alizarin uses Source Sans Pro Black Source Sans Pro Light
Repro with Version: 7.0.0.3 (x64) Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL and Version: 7.1.0.0.alpha0+ (x64) Build ID: c2864be448b52cdac0f8712708cb6c988155fdc8 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
hm, I can't repro it in Version: 7.1.0.0.alpha0+ (x64) Build ID: <buildversion> CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL build from 8 August 2020, but here is Windows 7 and Nvidia 1660 with latest driver so may it be only Win 10 problem?
I cannot reproduce. Version: 7.1.0.0.alpha0+ (x86) Build ID: CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-US Calc: threaded
I also don't repro with Version: 7.1.0.0.alpha0+ (x64) Build ID: 5bf71c698fb1d0a4c36aae86a01d0a99223c9d7a CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
(In reply to Mike Kaganski from comment #11) > I also don't repro with ... UI render: default Oh lol, I only looked at this after posting. Unfortunately, still repro with Version: 7.1.0.0.alpha0+ (x64) Build ID: 5bf71c698fb1d0a4c36aae86a01d0a99223c9d7a CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL
Does the problem still exist if you - try with GDI or OpenGL? - use a different font? - use a different locale than ru_RU?
(In reply to Luboš Luňák from comment #13) > Does the problem still exist if you > - try with GDI or OpenGL? As mentioned in comment 11, not repro with GDI; tested not reproducible with Version: 7.1.0.0.alpha0+ (x64) Build ID: e538c6991b092b108350bc5695fa6da454cf9470 CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: GL; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL > - use a different font? That's a great catch! Look at https://imgur.com/wpsj1OE, where the font names are also garbled in the font drop-down *only for some variants of Source fonts*. > - use a different locale than ru_RU? Also tested to be reproducible with Version: 7.1.0.0.alpha0+ (x64) Build ID: e538c6991b092b108350bc5695fa6da454cf9470 CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (ru_RU); UI: en-US Calc: CL
(In reply to Mike Kaganski from comment #14) > the font names are also garbled in the font drop-down *only for some > variants of Source fonts*. Specifically: Source Sans Pro Source Sans Pro Black Source Sans Pro Light Source Sans Pro SemiBold Removing Source Sans Pro Black installed in Windows\Fonts, and re-installing from one extracted from the MSI package, which is bit-to-bit identical to the previous one, fixed the issue for this font. Still unsure where the issue is - some installer issue registering it incorrectly (but visible to other apps, and to other backends)? Need to find where the difference (in registry?) is.
Interestingly, "Uwqteg" is "Source" and "Enkem" is "Click", if shifted by two in ASCII. That suggests something uses wrong glyphs for some reason. I have no idea how to debug this though, especially since I cannot reproduce locally. On thing you could try is to modify WinSkiaSalGraphicsImpl::DrawTextLayout() and comment out the call to createDirectWriteTypeface(), which should switch text rendering from DirectWrite to GDI.
*** Bug 135989 has been marked as a duplicate of this bug. ***
Since this is possibly a bug in Skia, one more thing you could try is to check other software that uses Skia, namely Chrome/Chromium. Does the problem show there too with the affected font?
Attaching example document and fonts from BUG135989 New fresh document which demonstrates the font rendering issue. Fonts as copied from /windows/fonts directory, 7z packaged
Created attachment 164536 [details] fresh document illustrating the font rendering issue from BUG135989
Created attachment 164537 [details] and the fonts, as copied from /windows/fonts, 7z packaged
(In reply to Luboš Luňák from comment #16) > Interestingly, "Uwqteg" is "Source" and "Enkem" is "Click", if shifted by > two in ASCII. That suggests something uses wrong glyphs for some reason. Nice find! > I have no idea how to debug this though, especially since I cannot reproduce > locally. While I could not make the Source Sans fonts to misbehave after reinstalling, I could repro the problem using the fonts from comment 21 and the document from comment 20. > On thing you could try is to modify > WinSkiaSalGraphicsImpl::DrawTextLayout() and comment out the call to > createDirectWriteTypeface(), which should switch text rendering from > DirectWrite to GDI. Making typeface to get its value from SkCreateTypefaceFromLOGFONT fixes the problem with the font ... (In reply to Luboš Luňák from comment #18) > Since this is possibly a bug in Skia, one more thing you could try is to > check other software that uses Skia, namely Chrome/Chromium. Does the > problem show there too with the affected font? I could not repro, neither in Chrome dialog (where I could try to modify the "standard" fonts), nor using an html like > <html><body><p style="font-family:Utopia">This is a <i>paragraph.</i></p></body></html> Note that in the Chrome dialog, I could not play with italics, which seem to be affected in the bugdoc from comment 20. Any other code pointer I could check (if you have an advise to make debugging easier)?
Reproduced on 7.0.0.3 on W10 x64 (don't have the exact info, I uninstalled this new version because of this bug). I don't use Skia, it happened anyway when using Source Sans Pro font – I think it hasn't anything to do with that. The behavior was the same when the font was used in svgs put into Writer (that's what I noticed first). By the way, I think it should be reproducable by just setting Source Sans Pro font in Writer.
(In reply to tomaskeb from comment #23) > I don't use Skia, it happened anyway when using Source Sans Pro font – I think it hasn't anything to do with that. Do you mean that you had disabled Skia explicitly when installed version 7.0? Otherwise, Skia would had been enabled automatically.
I was also able to reproduce with Optima font found according to https://ask.libreoffice.org/en/question/262065 ; I needed to install *two* fonts from the package ("OPTIMA.TTF", and "Optima Medium.ttf") to repro.
I'd like to bring the attention of people here to bug 137122, which looks similar to the duplicate 135989, but concerns ligatures (ff, fi, ffi) and dashes (both en-dash and em-dash) specifically, not all glyphs. That bug can be reproduced with Dejavu Sans font and should be easy to test. I'll leave others to decide if it's a duplicate of this one.
*** Bug 137148 has been marked as a duplicate of this bug. ***
Repro with LO 7.0.4.1 Version: 7.0.4.1 (x64) Build ID: e3cebc55238632eae061a3da668963d484a71147 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); Langue IHM : fr-FR Calc: threaded Same screenshot Idem With LO 7.1 dev Version: 7.1.0.0.alpha1+ (x64) Build ID: 312a33b7636334f6ce3b6d1702bc5d3e45215601 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Idem LO 7.2 dev Version: 7.2.0.0.alpha0+ (x64) Build ID: 4e63ec27b69fa01ff610c894c9fbf05c377a6179 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
*** This bug has been marked as a duplicate of bug 137122 ***