Bug 141047 - FORMATTING: Calc render 11pt font as 10,5pt when cell contains NBSP at 90% zoom
Summary: FORMATTING: Calc render 11pt font as 10,5pt when cell contains NBSP at 90% zoom
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2021-03-15 12:42 UTC by vladankudlac
Modified: 2024-05-20 17:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
example file with some cell containing non-breaking space (15.79 KB, application/vnd.oasis.opendocument.spreadsheet)
2021-03-15 12:44 UTC, vladankudlac
Details
For bug 141608 (224.65 KB, image/png)
2021-04-15 13:08 UTC, Harshita Nag
Details
screenshot-windows10 (173.94 KB, image/jpeg)
2021-04-15 15:16 UTC, vladankudlac
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vladankudlac 2021-03-15 12:42:12 UTC
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
Comment 1 vladankudlac 2021-03-15 12:44:23 UTC
Created attachment 170491 [details]
example file with some cell containing non-breaking space
Comment 2 Harshita Nag 2021-04-15 13:06:16 UTC
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.
Comment 3 Harshita Nag 2021-04-15 13:08:20 UTC
Created attachment 171219 [details]
For bug 141608
Comment 4 vladankudlac 2021-04-15 15:16:03 UTC
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.
Comment 5 Buovjaga 2022-04-01 08:44:22 UTC
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
Comment 6 vladankudlac 2022-04-03 19:26:42 UTC
Still reproducible with 7.3.1.3 (x64).
Disabling Skia doesn't make a difference. Still broken.
Comment 7 Rafael Lima 2022-04-26 20:32:24 UTC
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
Comment 8 vladankudlac 2022-10-30 20:04:40 UTC
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
Comment 9 BogdanB 2023-09-23 03:42:41 UTC
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.
Comment 10 Armondo Lopez 2024-04-03 20:15:36 UTC
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
Comment 11 Buovjaga 2024-04-04 06:32:20 UTC
(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.
Comment 12 vladankudlac 2024-04-04 08:50:44 UTC
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
Comment 13 BogdanB 2024-04-04 08:54:17 UTC
(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.
Comment 14 ady 2024-04-04 23:40:11 UTC
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
Comment 15 Buovjaga 2024-04-05 04:34:16 UTC
(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
Comment 16 ady 2024-04-05 20:51:16 UTC
(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.