Description: In a sheet in which cells are mainly set as currency, the currency symbol (which was previously fully indented to the far left of the cell) was now indented so much that it moves to the adjacent cell. The only way to fix this is to re-format each cell (as currency still). This moved the currency symbol together with the value (aka no indentation and no spacing). The format code of the cell pre re-formatting is: _-[$€-2] * #,##0.00_-;-[$€-2] * #,##0.00_-;_-[$€-2] * -??_-;_-@_- The format code of the cell post re-formatting is: [$€-43A]#,##0.00;[RED]-[$€-43A]#,##0.00 I also tried to change the format code to the below, but this still pushed the currency symbol way offset onto the adjacent cell: [$€-43A]* #,##0.00;[RED]-[$€-43A]* #,##0.00 Steps to Reproduce: 1. Simply open a spreadsheet that was created in a previous version, which has currency formatted cells, in the new release. Actual Results: The currency symbol is indented way off to the left, resulting in it overlapping into the adjacent cell (and if any data in that cell, it overlaps that data). Resizing the column won't have any affect. Expected Results: The currency should be perfectly indented to the left of the cell, while the value should be indented to the right, with perfect spacing in between for consistency. Reproducible: Always User Profile Reset: No Additional Info: No other information available.
Created attachment 192916 [details] Left image is indentation post update, right is post cell re-formatting. Previously, the currency sign is at the far left of the cell, unlike the new formatting.
Please provide a minimal sample ods file, preferably saved with an older version (that you know used to show the expected indentation and alignment), so other could attempt to reproduce what you see in your system. Please be aware that such sample ods file will be publicly available. <https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission>
In B1 enter a number and format with a currency format that left-aligns the currency symbol, like the mentioned [$€-43A]* #,##0.00;[RED]-[$€-43A]* #,##0.00 and then widen the column and see the symbol being shifted out to the left. See also https://ask.libreoffice.org/t/messed-up-currency-indentation-in-calc-after-update/102868
*** Bug 160091 has been marked as a duplicate of this bug. ***
(In reply to Eike Rathke from comment #3) > [$€-43A]* #,##0.00;[RED]-[$€-43A]* #,##0.00 > > and then widen the column and see the symbol being shifted out to the left. For those trying to replicate this: * Set an entire column with a custom format as Eike suggested or similar; for instance: [$€-409]* #,##0.00;[RED]-[$€-409]* #,##0.00 * This is easier to see/replicate when using different numeric values. Set one cell with 1.88, another with 12345.67, and another with 1 million. * This is easier to see when using the default cell alignment. * This is easier to see when using a proportional font (in contrast to using a fixed-width mono-spaced font). In fact, using a mono-spaced font you might not see the displacement at all. * This is easier to see when the apparent space between the currency symbol and the number is intentionally much wider than needed. > Set the width of the column intentionally _much_ _wider_ than the minimum needed. * This is easier to see when varying the zoom slider in Calc. While modifying the zoom factor, in some cases (i.e. zoom values) you might not see the problem, whereas with some other zoom factors – just move the zoom slider – the problem will be more evident. While the problem can be seen in LO 24.2.0.3 already, I am not completely sure that the behavior in a recent alpha is _exactly_ the same; the problem is still there, but maybe there is something else too. Since there seems to be some misalignment in LO 7.6, this might be some implementation error while trying to solve such a problem. But since I am not sure, and the behavior is not seen in LO 7.6, I am setting this as a regression for now.
*** Bug 161437 has been marked as a duplicate of this bug. ***
No repro with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f6ea343e6fb2dc3539823dee60c9c6f96fc16275 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
Still reproduced following comment 5. Please remember to use a column (much) wider than strictly needed (not the "optimal" width), and to vary the zoom level ([CTRL]+mouse_wheel) in order to see the problem more easily/clearly. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 8501cb20627e5bc36d760b53b0990f4105c4ff65 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded
Created attachment 195284 [details] LOcalc currency character placement bug Can confirm issue on post 24 versions of LOcalc (*buntu, Mint, Arch). Issue does not occur with same documents (.ods) in pre 24 versions (7.3, 7.4, 7.6 on *buntu, Debian, Mint). Due to earlier "similar" issues, checked with and without libreoffice-gtk3: issue persists. See attachment (webm) for illustration of issue. As mentioned by @ady currency character placement occurs/ does not adapt when column width is "non-optimal"
It looks like this bug can be closed, since... Version: 24.8.0.1 (X86_64) / LibreOffice Community Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded ...functions as expected.
If so (didn't check), then it would be good if someone could determine what commit(s) fixed it so we can backport those to 24.2.
Still repro as of: Version: 24.8.0.1.0+ (X86_64) / LibreOffice Community Build ID: 982c262b479a5326925c13dfb7fb258901c6f348 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded
There's a bibisectRequest since 2024-03-08, would be nice if QA could provide such.
Created attachment 195459 [details] screenshots bug 160002 following comment 5 odg I am attaching a 1-page Draw odg file that shows screenshots of how I see the values by following the details in comment 5 under the conditions of this tdf#160002. Depending on zoom factor (YMMV), the "€" symbol can be seen too far to the left (outside the left-side limit of the cell). With other zoom levels (and depending on the numerical value in the cell), the position of the "€" symbol varies. This is reproduced with LO 24.2, but not (so much) with LO 7.6.6. In LO 7.6.6, the location of the "€" symbol might vary slightly depending on zoom level and cell’s numerical value, but it is never displayed far outside the cell limit (nor far inside it). The resulting (unexpected/undesired) render is seen on the main spreadsheet area, but not on print preview.
Still reproducible in: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 01e6e4303e5a9966f102e0357fe0354a2f74a1c4 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 195656 [details] Sample spreadsheet bug 160002 I am attaching an ods file with very simple instructions. Hopefully this helps for bisect.
Regression after 4b743de97fc133623e46827869c4ea3eb845ad47.
*** This bug has been marked as a duplicate of bug 160786 ***
I apologise: I reported earlier the bug was resolved with Version: 24.8.0.1 (X86_64). I now found _it is not_, nor does it seem to be resolved for earlier 24.X versions, which, by now, have received several update iterations. TLDR: all libreoffice-calc versions ≥ 24.2 have this bug, including Fresh and Pre-release. Some clients, adamant to preserve financial productivity, have asked me to revert, which is cumbersome since 7.X versions are not readily available in all distro repos, and Old-Still LO PPA dismisses 24.04 LTS installs.
(In reply to Bella vGFH from comment #19) Just look at tdf#160786, which this bug is a duplicate of. It is fixed in 24.8.1, as seen in its "whiteboard", and its commit notifications.
(In reply to Mike Kaganski from comment #20) > (In reply to Bella vGFH from comment #19) > > Just look at tdf#160786, which this bug is a duplicate of. It is fixed in > 24.8.1, as seen in its "whiteboard", and its commit notifications. THX Mike, that is great to hear! Some follow-up Qs if you allow me... [1] Will this fix also trickle down to 22.04.X installs? (Since distro repos move slow ;))) [2] Is it also available as diff so it can be patched independantly of repo action? THX again! Bella
(In reply to Bella vGFH from comment #21) > [1] Will this fix also trickle down to 22.04.X installs? (Since distro > repos move slow ;))) (a) there is no "22.04.X", there are only 24.2.X. (b) as said - the information is there, in bug 160786. You can see there, that it wasn't ported to 24.2. > [2] Is it also available as diff so it can be patched independantly of repo > action? And as mentioned, there are commit notifications there, which point to the commits - that show you the diffs. Indeed, you can also get the diffs from git, the hashes are in the commit information.
(In reply to Mike Kaganski from comment #22) > (In reply to Bella vGFH from comment #21) > > [1] Will this fix also trickle down to 22.04.X installs? (Since distro > > repos move slow ;))) > > (a) there is no "22.04.X", there are only 24.2.X. Ooops, my typo, my bad. Sorry... > (b) as said - the information is there, in bug 160786. You can see there, > that it wasn't ported to 24.2. That was indeed what I wanted to know. THX for anticipating my typo. > > > [2] Is it also available as diff so it can be patched independantly of repo > > action? > > And as mentioned, there are commit notifications there, which point to the > commits - that show you the diffs. Indeed, you can also get the diffs from > git, the hashes are in the commit information. Got it. THX again!