Description: I set default font using default template to 11pt Calibri. When using zoom 100% everything is OK, but when zoom is set to 90%, some cells are displayed smaller, and 11 pt looks exactly same as 10,5 pt. Cells with smaller font contains non-breaking space, removing space makes the font normal and inserting NBSP make the font smaller again. My screen is 2560x1440, with 125% scale. Steps to Reproduce: 1. Open attached file 2. Set zoom to 90% 2. Compare font size of "speechEngineExecute" vs. "D/SE_elapsed sampler:" 3. Remove space from any smaller cell or add non-breaking space to normal font cell Actual Results: Font size of cells with non-breaking space is smaller than it should be. Expected Results: Same font size for all cells set to 11pt. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.1.2 (x64) / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
Created attachment 170491 [details] example file with some cell containing non-breaking space
Hello vladankudlac@gmail.com, I cannot reproduce this bug on my system. Following are the details: Version: 7.1.1.2 / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded Point 5, 10, 11 are different and I cannot see any difference in font sizes. I have added an attachment of the screenshot for how it looks when I set the font size to 90 % Additional info: My screen is 1920x1080, with a 100% scale.
Created attachment 171219 [details] For bug 141608
Created attachment 171223 [details] screenshot-windows10 Tried it again and the problem persists. I removed non-breaking spaces from lines with green arrow and you can see different font size redered.
Not reproduced. Does it make a difference, if you deactivate Tools - Options - LibreOffice - View - Use Skia for all rendering? Or do you still reproduce with 7.3? Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 040b3198fde3385e19e7380fdcabae84a0abac9d CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo
Still reproducible with 7.3.1.3 (x64). Disabling Skia doesn't make a difference. Still broken.
I could not reproduce the issue. I added NBSP to various cells and the font size rendered correctly. I tested using kf5 on Kubuntu 21.10. Maybe a Windows-only problem? System info: Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 12; OS: Linux 5.13; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Ubuntu package version: 1:7.3.2~rc2-0ubuntu0.21.10.1~lo1 Calc: threaded
Still reproducible with 7.4.2.3. Version: 7.4.2.3 (x64) / LibreOffice Community Build ID: 382eef1f22670f7f4118c8c2dd222ec7ad009daf CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: cs-CZ Calc: CL
Vlad, could you try a user profile reset? Start LibreOffice and select Help ▸ Restart in Safe Mode. In the Enter Safe Mode dialog select Restart. LibreOffice will restart and display the Safe Mode dialog. Please come back here with some feedback.
I was unable to reproduce the bug in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded or Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to BogdanB from comment #9) > Vlad, could you try a user profile reset? > > Start LibreOffice and select Help ▸ Restart in Safe Mode. > In the Enter Safe Mode dialog select Restart. > LibreOffice will restart and display the Safe Mode dialog. > > Please come back here with some feedback. Needinfo while we wait for feedback and also results with version 24.2.
I'm still able to reproduce it with different computers, Fail-Safe mode and: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: cs-CZ (cs_CZ); UI: en-GB Calc: threaded
(In reply to vladankudlac from comment #12) > I'm still able to reproduce it with different computers, Fail-Safe mode and: > > Version: 24.2.2.2 (X86_64) / LibreOffice Community > Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 > CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: > win > Locale: cs-CZ (cs_CZ); UI: en-GB > Calc: threaded Someone else need to confirm someone else bugs. So, we just need to wait for someone else to reproduce the bug.
I can reproduce this with specific zoom values; in my case these are: 90%, 210%, 390%. This is easier to see when comparing the _horizontal_ length of 2 similar text values, each on adjacent cells, one on top of the other (e.g. cells A1 and A2). For instance: A1: D/SE_elapsed sampler: A2: D/SE_elapsed sampler: ...where cell A1 contains a NBSP character and A2 replaces it with a simple space character. Column A must use a font size of 11pt, and the zoom factor (in my case) is either 90% or 210& or 390%. The horizontal difference can be clearly seen (in my case) at the end of the underscore in this example, but it doesn't seem to be related to one specific character/position; it is rather an accumulative difference that by the 5th glyph is more evident. I can see the difference also before the underscore, but it is less clear – you have to be aware of this issue and be looking for this difference. Changing the zoom factor makes the render equivalent/equal in both cases; space character vs NBSP, or A2 vs A1 in my example. Changing the NBSP character by a simple space character makes the horizontal length change. I can also repro this with other fonts (e.g. Arial, Consolas, Liberation Mono, Liberation Sans, Noto Sans...), but always with 11pt; not repro with other sizes. I am not sure whether it happens with so-called "variable" fonts (vs. "static" fonts, not related to monospaced fonts). Perhaps this is just a matter of how the specific font size (11pt) is scaled/rendered in Calc. FWIW, I don't see this difference with AOO 4.1.15. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1344e6261a1d856c71eca1e0cc29215a586bf335 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded
(In reply to ady from comment #14) > FWIW, I don't see this difference with AOO 4.1.15. Then let's treat this as a regression. Users who can reproduce are encouraged to bibisect: https://wiki.documentfoundation.org/QA/Bibisect/Windows https://wiki.documentfoundation.org/QA/Bibisect
(In reply to Buovjaga from comment #15) > Then let's treat this as a regression. IDK about that; it might or might not be a regression. In LO 3.3.0.4, there is also a horizontal difference, but: * the specific zoom factors that show the difference might not be the same as in a recent 24.8 alpha, * the horizontal difference might be "inverted". Using the example from comment 14 and with a zoom factor that shows some difference in the horizontal length, cell A1 might be shown "longer" than A2 in LO 3.3.0.4, but in a recent 24.8 alpha cell A1 is shown "shorter" than A2. So, perhaps the difference in LO 3.3.0.4 is caused by something else; or maybe the basic reason is the same with some "minor" change in some commit.