Description: Open attached: Two cells, B2, F2 not wide enough Select columns A to Z Double click a column boundary: all cells now completely visible. Format>Columns>Optimal Width [OK] Two cells, B2, F2 not wide enough: show "#"'s. Steps to Reproduce: See above Actual Results: See above Expected Results: See above Reproducible: Always User Profile Reset: No Additional Info: This may be related to Bug 158689.
Created attachment 191723 [details] Exhibits bug 158997
No issue for me: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
(In reply to m.a.riosv from comment #2) > No issue for me: Do you mean either that you can't reproduce the behaviour I have documented, or that you don't think that this behaviour is a bug, or both of the above? Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
I can't reproduce.
I tried running in safe mode and I still get the result in my original description. Can you suggest anything I'm doing to get the unexpected behaviour?
I noticed that you were using openCL, whereas I was not: I have changed to use openCL. Now when I run in safe mode, Open attached: Two cells, B2, F2 not wide enough Select columns A to Z Double click a column boundary: all cells now completely visible. Format>Columns>Optimal Width [OK] All as expected: no narrow columns. However, Open attached: Two cells, B2, F2 not wide enough Select columns A to Z Double click a column boundary: all cells now completely visible. Format>Columns>Optimal Width *** Change 0.20 cm to 0.00 cm [OK] *** Two cells, B2, F2 not wide enough: show "#"'s.
(In reply to David Lynch from comment #6) > ..... > Format>Columns>Optimal Width > *** Change 0.20 cm to 0.00 cm [OK] *** > Two cells, B2, F2 not wide enough: show "#"'s. This case I can reproduce Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
First version where I can reproduce the issue. Version: 6.4.7.2 (x64) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: GL; VCL: win; Locale: es-ES (es_ES); UI-Language: en-US Calc: CL Last working for me: Version: 6.0.7.2 (x64) Build ID: 78c12ce5f2b8960f18b204a7ea82f971769f1679 CPU threads: 16; OS: Windows 10.0; UI render: GL; Locale: es-ES (es_ES); Calc: CL
It happens only with optimal with 0,00 with 0,01 works fine.
Please note that it also depends on Font type, Font size and Zoom factor. For instance, use Liberation Mono as font > no repro. It also depends on content. For instance, in attachment 191723 [details], change cell F2 to contain "111" (without quotes) and it is easier to reproduce, but change the content to "888" (without quotes) and repeat the procedure; then the content is seen (not the "###"). Same goes for cell B2, "11" makes it easier to repro, but with "88", no repro in that cell.
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.4. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 5cf430af43b97e4130348b5075ed4af004e5a624 is the first bad commit commit 5cf430af43b97e4130348b5075ed4af004e5a624 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Jan 5 20:59:16 2022 +0100 source ae406d7acc985c56bacd7c0e0c9658170afa907d 128007: upgrade to latest harfbuzz | https://gerrit.libreoffice.org/c/core/+/128007 Used this trick - change cell F2 to contain "111" (without quotes) and it is easier to reproduce.
With attachment 191723 [details] I can repro the behavior since LO 6.1 and newer, but not in LO 6.0 and older. In the following procedure, please do not confuse "Column width" with "Optimal width"; we are referring to the latter (and the "Add" field in it set to zero), not the former. STR: 0. (Optional) Set the zoom factor to be comfortable. During the rest of the procedure, do not modify the zoom (as it is also a relevant factor). 1. Open attachment 191723 [details]. 2. Select column headers A:Z. 3. Double click between column headers F and G. Note that the complete contents of cells F2 and B2 are displayed. 4. With columns A:Z still selected, open menu Format > Columns > Optimal width. 5. In the Optimal width dialogue, set the "Add" box value to 0 (zero); OK. Note cells F2 and B2, showing "###". 6. Modify cell's F2 content, from 511 to 888 [ENTER]. 7. Select column headers A:Z. 8. Open menu Format > Columns > Optimal width. 9. In the Optimal width dialogue, set the "Add" box value to 0 (zero); OK. Note that the content of cell F2 is now displayed.
Presumably it was some change in harfbuzz that triggers the problem, in an ideal world we could easily bisect through the harfbuzz commits between 2.8.2 and 3.2.0 to see what that was. However we are now at version 8.2.2 of harfbuzz so that's a huge leap away from the detected harfbuzz difference. Following the 'change cell F2 to contain "111" (without quotes) and it is easier to reproduce' hint I can reproduce this on Linux with my latest build. Debugging I see that the actual text rendering is done with kerning disabled, while the optimal size calculation is done with kerning enabled and that's a likely candidate for the difference.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1bcb7d4bdaecaf37353e37fe09373189e62d69dd Resolves: tdf#158997 optimal col width too narrow to render text It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
That at least solves what I saw which is hopefully the same as initially reported. backports to 24.2 and 7.6 in gerrit
Thanks @Caolan. Verified Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 25276df12abd9d002f7f899900434617b256f745 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
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/000aa433fd7a112b83ee0b629aa6edf4d9833277 Resolves: tdf#158997 optimal col width too narrow to render text It will be available in 24.2.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/441ae3c0bce0febe37b99b43fc09f2c30ae4a4ee Resolves: tdf#158997 optimal col width too narrow to render text It will be available in 7.6.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Caolán: Thanks for working on this issue. Would you please explain what your patch exactly does? I just want to make sure that it properly respects the character properties "Pair kerning". (Your patch SHOULD NOT ALWAYS calculate the width with kerning disabled. It SHOULD respect the character properties.)
Since https://cgit.freedesktop.org/libreoffice/core/commit/?id=36eed54d3dfed6551fd2ad944feff7e217c56e82 text is rendered without kerning while the optimal col width measurement continued to take place without any explicit kerning on or off, so defaulted on. And the kerned text width is typically a little narrower than the non-kerned width. So I've just matched the optimal col width calc to default to an explicit kerning off to match how it will be rendered
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 As I said in prior posts, the result also depends on zoom percentage, among other factors. Even without any issues whatsoever, the exact rendering after an "optimal width" action has been always dependent on the zoom %. I can still reproduce a similar behavior as before. In my case, when I set the "Add" field of the Optimal width dialogue to zero, and I leave the zoom at the original 90%, I can see some cells as "###" (again F2, among those). Now I change the zoom to 110% > all cells seen correctly (without performing any action other than changing the zoom). I keep modifying the zoom, up to 160%. Some cells are displayed as "###" (as expected, because modifying the zoom _after_ an "optimal width" action will always have this effect). Once I select the columns and repeat the "Optimal width" action (with the right-click context menu), I see all the cells as expected (no "###"). Going back to 90% zoom, some "###" show up again – no surprise there. All this was always tested with the "Add" field in zero. The improvement is that the rendered width is not varying with content. Whether cell F2 contains 111 or 888, the result is the same. Problem 1: users expect to see the entire content when they apply "optimal width" (as long as the column/cell was selected). Since the issue is happening when the "Add" field is zero, then there is probably something related to this field (or to some consequence of its value). Problem 2: the "optimal width" dialogue generates a different result than the double-click between headers, with the same exact entire columns/cells selected.
(In reply to Caolán McNamara from comment #20) > Since > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=36eed54d3dfed6551fd2ad944feff7e217c56e82 text is rendered without > kerning while the optimal col width measurement continued to take place > without any explicit kerning on or off, so defaulted on. And the kerned text > width is typically a little narrower than the non-kerned width. > > So I've just matched the optimal col width calc to default to an explicit > kerning off to match how it will be rendered Hi Caolán, thanks for working on this. However this is the wrong approach. Text is NOT always rendered with kerning=off. This is just the default character formatting. Your patch should consider the real character formatting regarding kerning. Your patch will lead to too wide cells in case kerning is turned on for the whole or a part of the cell content text. Please look also look at issue 118221 to understand, what the correct behaviour is. I vote for revoking your patch until it respects the reals character formatting.
https://bugs.documentfoundation.org/show_bug.cgi?id=118221
Created attachment 192092 [details] kerning_optimal_cell_width_testkit.ods
Added testkit. @Caolán: Please check and report calculated optimal width of columns B with your patch.
(In reply to ady from comment #21) Let's track the zoom issue elsewhere, e.g. bug 95007 but there might be others. > Problem 2: the "optimal width" dialogue generates a different result than > the double-click between headers, with the same exact entire columns/cells > selected. Please see bug 158689. (In reply to OfficeUser from comment #25) > @Caolán: Please check and report calculated optimal width of columns B with > your patch. At default zoom level, using Format > Columns > Optimal width > O cm extra: - LO 7.6.4.1: 20.97 cm (cell B1 "overflows" at default zoom level) - recent daily build that contains Caolán's patch: 21.46 cm, matches the longest content's width Also tested with only B1 or only B2 contents, works well. So I see it resolved now. Further issues can be tracked elsewhere. (changed version field according to bibisect, although it doesn't match comment 8's observation)
(In reply to Stéphane Guillou (stragu) from comment #26) > At default zoom level, using Format > Columns > Optimal width > O cm extra: > - LO 7.6.4.1: 20.97 cm (cell B1 "overflows" at default zoom level) I can exactly confirm this. That means builds before Caolán's patch calculate good column width for Pair kerning = on. Now the questions remains if the exactly same (good) results for Pair kerning = on are also achieved with the patch. Can you confirm that builds WITH the patch included still calculate 20.97 cm for B2 (yellow cell with Pair kerning = on)?
I mean 20.97 cm for B2 only.
The patch is only acceptable if it improves the situation for Pair kerning = off while it does NOT degrade the situation for Pair kerning = on. That is what I would like to make sure.
OK, let me clarify. Instead of testing two distant versions, I tested right before and right after Caolán's 1bcb7d4bdaecaf37353e37fe09373189e62d69dd patch to isolate only its effect. Testing at 100% zoom level, 0 cm extra (optimal column width will always change depending on zoom level, so changing the zoom level after setting the column width will always create a mismatch). Before patch: - pair kerning off: 20.97 cm (wrong, text overflows column) - pair kerning on: 21.11 cm (fits column) With patch: - pair kerning off: 21.46 cm (fits column) - pair kerning on: 21.11 cm (fits column) So, conclusion: - optimal width fixed for pair kerning off - optimal width unchanged for pair kerning on (note that the text width for pair kerning on has slightly increased somewhere between 7.6.4 and patch~1, which explains the slight change from 20.97 to 21.11 in my previous test.) So patch is correct. Marking as verified.
Created attachment 192171 [details] comparison before and after patch for pair kerning on vs off
> (note that the text width for pair kerning on has slightly increased somewhere between 7.6.4 and patch~1, which explains the slight change from 20.97 to 21.11 in my previous test.) How do you come to that conclusion, that this is not caused by Caolán's patch?
(In reply to OfficeUser from comment #32) > > (note that the text width for pair kerning on has slightly increased somewhere between 7.6.4 and patch~1, which explains the slight change from 20.97 to 21.11 in my previous test.) > How do you come to that conclusion, that this is not caused by Caolán's > patch? As I said in the QA chat: Because it is already the case at the commit before Caolán's commit. That's what I meant by "patch~1". It looks like it's width of the text, not optimal width column, so it might have been a change in font rendering. It looks like a very minor change and I can't see a difference, but I've got limited knowledge in that area. If you spot a difference and think it's an issue, you can open a bug report and the change can likely be bibisect.