Bug 160921 - Changing Add in Columns->Optimal width causes some columns to be too narrow
Summary: Changing Add in Columns->Optimal width causes some columns to be too narrow
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering Cell-Management
  Show dependency tree / graph
 
Reported: 2024-05-03 10:35 UTC by David Lynch
Modified: 2024-05-10 05:34 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:

Attachments
Exhibits bug 160921 (35.12 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-05-03 10:39 UTC, David Lynch 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Lynch 2024-05-03 10:35:58 UTC 
Description:
See attached spreadsheet. 
Select all cells.
Format->Columns->Optimal Width, set Add to zero
Some columns are too narrow to display data (eg column A)

Steps to Reproduce:
See description

Actual Results:
See description

Expected Results:
All columns should display data no ###


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 12; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded

Same result in safe mode.
Comment 1 David Lynch 2024-05-03 10:39:07 UTC 
Created attachment 193950 [details]
Exhibits bug 160921
Comment 2 m_a_riosv 2024-05-03 21:53:58 UTC 
Reproducible
Version: 24.2.2.2 (X86_64) / LibreOffice Community
Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

but works fine doing:
- Select all
- Double click between column head separators.
Comment 3 m_a_riosv 2024-05-03 22:32:05 UTC 
Last version working for me
Version: 7.6.6.3 (X86_64) / LibreOffice Community
Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: es-ES
Calc: CL threaded

The first bad for me:
Version: 24.2.0.0.alpha1 (X86_64) / LibreOffice Community
Build ID: 06946980c858649160c634007e5fac9a5aa81f38
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded

Reproducible also with
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f4ef5435df5560e6b6b061ce4053c71e2819bf51
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: CL threaded
Comment 4 ady 2024-05-04 02:29:17 UTC 
Isn't this a consequence of OP's own prior report tdf#158997? Or, a simple (false) dupe?

What is the precise difference between tdf#158997 and this new tdf#160921? It is important to understand the difference and exact report/request in order to actually solve it.
Comment 5 gladys 2024-05-09 16:35:23 UTC 
bibisect from 24.2 in windows 10 to 4b743de97fc133623e46827869c4ea3eb845ad47
Don’t round glyph coordinates when doing subpixel positioning
Comment 6 Buovjaga 2024-05-10 05:34:03 UTC 
(In reply to gladys from comment #5)
> bibisect from 24.2 in windows 10 to 4b743de97fc133623e46827869c4ea3eb845ad47
> Don’t round glyph coordinates when doing subpixel positioning

Result verified with bibisect-linux-64-24.2 repo.