Description: There appears to be an error or conflict in the optimal column width processing subject to the character formatting of spacing (kerning) and PAIR kerning. This may also impact or provide further insight into Bug 122664 Steps to Reproduce: With the attached sheet Focus F2 and select all the text inside that cell either right click and select "Character" or MENU>Format>Character Select the position tab and observe the character spacing Activate the pair kerning tick box OK Select column F Right Click Optimal Width Add 0.00cm Deselect Default value OK Again focus and select all the text in F2 Right Click and select Character remove the 0.2pt kerning adjustment factor and deselect pair kerning OK Observe the text overflow is suppressed by the contents of G2 - Which is specifically pair-kerned and optimised to identify the anomaly Select and right click column F header Optimal Width with zero addition and deselected default value OK Observe the column now shrinks to magnify the overflow "error" You may even wish to select both cells and set the font size to 40pt, then optimise column width for both columns. The workaround is to set all the typography manually - which rather defeats the objective of the automation Actual Results: Incorrect Column Width Optimisation Expected Results: Correct Column Width Optimisation Reproducible: Always User Profile Reset: No OpenGL enabled: Yes Additional Info: Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: sv-SE (en_GB); UI: en-GB Calc: threaded
Created attachment 177823 [details] Demonstration of impact of "kerning" on Optimal Column Width
Perhaps one of the "Big Boys" may decide whether to mark this as a duplicate - I wasn't 100% convinced but I am open to suggestion
Shorter steps: 1. Open attachment 177823 [details] 2. Focus F2, select text, right-click - Character 3. Set Character Spacing to 0 4. Make column F narrower, so the overflow is cut 5. Right-click heading of column F, Optimal width: 0 Width is not increased enough. Bibisected with linux-64-6.1 to https://git.libreoffice.org/core/commit/8bb1ab5c4456526e2411ba8f953e41daef8b429b Resolves: tdf#118221 whole cell kerning default is off Not really a regression, but an unwanted side-effect. Eike: what do you think?
0,20 cm in my (In reply to Buovjaga from comment #3) > Shorter steps: > 1. Open attachment 177823 [details] > 2. Focus F2, select text, right-click - Character > 3. Set Character Spacing to 0 > 4. Make column F narrower, so the overflow is cut > 5. Right-click heading of column F, Optimal width: 0 > > Width is not increased enough. > > Bibisected with linux-64-6.1 to > https://git.libreoffice.org/core/commit/ > 8bb1ab5c4456526e2411ba8f953e41daef8b429b > Resolves: tdf#118221 whole cell kerning default is off > > Not really a regression, but an unwanted side-effect. > > Eike: what do you think? 0,20 cm in my case after step 5. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0f2581204a70038ed7ca78089a9bd96d158e02c0 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Is identifying alternate methods for proving the anomaly helping to identify or eliminate potential culprits? The sample file you're all utilising contains the pair kerning I "manually" applied and the additional "proofs" just seem to confirm that manual kerning affects the integrity of the auto column width.
I wonder if the change from bug 158997 will make any difference to this case
(In reply to Caolán McNamara from comment #6) > I wonder if the change from bug 158997 will make any difference to this case Still the same result in 7.6.4 and master with steps from comment 3. The last half of the last W remains hidden. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e83c7ec2f4d801365235bf56d7cc8cf31ef4a00e CPU threads: 8; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
> (In reply to Caolán McNamara from comment #6) > > I wonder if the change from bug 158997 will make any difference to this case > > Still the same result in 7.6.4 and master with steps from comment 3. The > last half of the last W remains hidden. Different report here. Following STR from comment 3... Using LO 7.6.3.2, the width is not increased enough. Using: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 25276df12abd9d002f7f899900434617b256f745 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 Built: 2024-01-06 Following STR from comment 3, I don't see the same problem as before. In this case, I have not tested with other conditions (such as a different zoom %). OTOH, in bug 158997 I still see some issue. I reported there my feedback.(In reply to Buovjaga from comment #7)