https://bugs.documentfoundation.org/show_bug.cgi?id=158997
--- Comment #21 from ady <[email protected]> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
