Description: In cells expecting currency in USD, the dollar sign is near the left edge of the cell in 7.5.4.1, but in 24.2.1.2 it gets shifted further left so it's on the left border of the cell. While this isn't a functional bug, it makes me wonder what other artifacts there may be. Steps to Reproduce: 1.open the file and look. 2. 3. Actual Results: Dollar sign is aligned on left border of cell Expected Results: Dollar sign lies completely inside the cell. Reproducible: Always User Profile Reset: Yes Additional Info: 3 files: format_test.xlxs screenshot_7.5.4.1.png screenshot_24.2.1.2.png
Created attachment 193810 [details] Excel file to demonstrate format error
Created attachment 193811 [details] screenshot of expected formatting
Created attachment 193812 [details] screenshot of formatting under 24.2.1.2
It doesn't happen with monospaced fonts. Neither Skia options have affect. And Safe Mode doesn't help. Reproducible with: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 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. since Version: 24.2.0.0.alpha1 (X86_64) / LibreOffice Community Build ID: 06946980c858649160c634007e5fac9a5aa81f38 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded But not reproducible with master Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 05a1217921b7be283c6750a35b90e4feda6e993e 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. Regression from 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
Created attachment 193814 [details] Misalignment ODS test Although I am not completely sure, I think I can replicate the problem with LO 24.8 alpha built today 2024-04-23. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ea43cbbb7371a743f470d949762a0e92f196e652 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 I am attaching a simple ods file. STR: 1. Open the attachment 2. Modify the zoom factor; zooming-out shows the problem easier, but also zooming-in (e.g. [CTRL]+(mouse wheel)). The misplacement (or misalignment) of the "$" sign is seen under some zoom factors, especially when zooming-out to very small zoom values. 3. (Optional) The cells' alignment is set to "default", so the visual effect is seen on the left side of the cells. If the column/cells are changed to align to the left, then the visual effect is seen on the right side (on the numbers) when modifying the zoom factor. Note that the visual effect is not seen with mono-spaced fonts, or at least not so clearly. Up to LO 7.6.5.2, the visual misplacement according to zoom factors is relatively small. OTOH, since LO 24.2, the misplacement/misalignment is much evident (up to a diagonal completely out of the cell borders when using some very small zoom factors). It should be noted that this behavior might be an unwanted consequence of a valid modification; it might be unavoidable. I tend to use mono-spaced fonts when (numeric) alignment is desired.
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Adding Cc: to Khaled Hosny ; Could you possibly take a look at this one? Thanks 4ce9836c2406d6fc50482782ef4675b5e5078edb is the first bad commit commit 4ce9836c2406d6fc50482782ef4675b5e5078edb Author: Jenkins Build User <tdf@pollux.tdf> Date: Sun Jul 23 06:26:11 2023 +0200 source 4b743de97fc133623e46827869c4ea3eb845ad47 154292: tdf#156234: Don’t round glyph coordinates when doing subpixel positioning | https://gerrit.libreoffice.org/c/core/+/154292
This only occurs at 100% display scaling for me with the bugdoc. A bit of debugging showed that there are several calls to GenericSalLayout::LayoutText(...), but in some cases GetSubpixelPositioning() ends up being true, messing up the calculations here (previously the values were always rounded): https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/CommonSalLayout.cxx?r=0b6a07f0#715
*** Bug 160002 has been marked as a duplicate of this bug. ***
From tdf#160002 comment 16: Attachment 195656 [details] (sample spreadsheet bug 160002). ODS file with very simple instructions; shows the problem and can very easily test when a fix is committed.
ATM this report is set as trivial. IMHO, this should be at least raised to normal (for broad impact and regression).
The root cause for this bug is accumulated arithmetic error in ScDrawStringsVars::RepeatToFill(). The VCL code change linked above is working correctly. The example document uses a custom format code containing a repeat character (in this case, the space character). To determine how many copies of the repeat character to insert, Calc measures the integer width of a string containing only that repeat character, then divides the width of the remaining space by that width. This approach is, unfortunately, not ideal. Characters in strings may not have integer widths, and with features like kerning and contextual alternatives, the widths may not even be uniform within the same string. As seen here, the resulting error can be significant.
(In reply to Jonathan Clark from comment #11) > The example document Please see comment 9, with simple ods containing simple instructions. In older versions (e.g. LO 7.6), the erratic behavior (see instructions in within the ods file) was either not detectable or not present. Since LO 24.2, the unwanted behavior is clearly seen.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/981c5780da8ec6b6878de58909b7cc7e736ad33a tdf#160786 sc: Fix repeat char format code inaccuracy It will be available in 25.2.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.
(In reply to Commit Notification from comment #13) > Jonathan Clark committed a patch related to this issue. Great! As a thought about a possible follow-up improvement, we could do better for special case of whitespace fill characters - which is the most common case - both positioning-wise, and performance-wise: we could just paint the parts separately at specific positions in the cell, avoiding constructing temporary fill string, calculating its width, constructing a new fill string and inserting the fill string into the final cell text. That could be done at the calls to mpDev->DrawText(Array) at the end of ScOutputData::LayoutStrings.
(In reply to Mike Kaganski from comment #14) ... and maybe even generally, for all cases, by drawing the three parts (text before, text of fill, text after) separately (similar to how fill character is drawn in Writer's ToC). It would need care to handle RTL correctly, but that's where you are THE expert :-)
(In reply to Mike Kaganski from comment #14) > As a thought about a possible follow-up improvement, we could do better for > special case of whitespace fill characters - which is the most common case - > both positioning-wise, and performance-wise: we could just paint the parts > separately at specific positions in the cell For the proportional whitespace case, I really like this idea. With whitespace padding there will always be some stagger in the left-aligned text, which doesn't look great. Rendering the two parts separately would fix that. I'm not sure what users would expect for the monospaced whitespace case. (In reply to Mike Kaganski from comment #15) > ... and maybe even generally, for all cases, by drawing the three parts > (text before, text of fill, text after) separately Since it's come up, I'll offer a general rule of thumb :) Treat draw calls as though readers can physically see them, and understand them as separating text. If your intention is to separate text, go ahead - but if you want people to see a contiguous portion of text, it needs to be rendered in a single draw call. In this case, for example: If these three parts are, semantically, three separate fields, then rendering them in three separate calls is completely fine. There will be "seams" between the parts, more or less visible depending on the user's language. If you want it to look like a single piece of text in all languages, though, you have to assemble the complete string ahead of them. The RTL/CTL fixup for this change would be restoring the current implementation.
(In reply to Jonathan Clark from comment #16) Of course, if you manually tweak the dx array used for text drawing, you can implement it in one operation. Not sure it's worth it, because not all codepaths use the arrays, so you would add more complexity by forcing single-pass text drawing. We split text to pieces left and right, because our software handles text in so many interesting ways - it's not possible to do it all in an ideal way.
(In reply to Mike Kaganski from comment #17) > (In reply to Jonathan Clark from comment #16) > > Of course, if you manually tweak the dx array used for text drawing, you can > implement it in one operation. Not sure it's worth it, because not all > codepaths use the arrays, so you would add more complexity by forcing > single-pass text drawing. We split text to pieces left and right, because > our software handles text in so many interesting ways - it's not possible to > do it all in an ideal way. I'm worried I might have overstated things! I would have said people are already doing a good job following that rule of thumb. To clarify, it wouldn't be a problem to use separate draws for the left-aligned and right-aligned parts, as described in comment #14. There's a logical separation in that text. No need to worry about manual advance adjustment. Comment #15 would be a user-visible behavior change. For a concrete example, a cell rendered today as "بججججججد" would turn into "بججججججد". I think there's a reasonable argument for that, but I'd hate for it to be a surprise.
Jonathan Clark committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/ca1bbfd1585e3b38ba9b0046b1c6960cd24f9c0e tdf#160786 sc: Fix repeat char format code inaccuracy It will be available in 24.8.1. 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.