Created attachment 141655 [details] contains the charts whose resize preview is shown wrong Document origin: Charts in the attached calc-doc were copied from another file (which in turn was imported from a MS Excel .xls sheet) (with "paste special", option "Star Object Descriptor (XML)"); sheet1 "misure" is a perfect copy of part of the original sheet, while sheet2 "calcoli" doesn't contain formulae, because I only needed to prepare the thing for printing. Then I have modified page breaks with "Menu -> View -> Page break" mode. Resizing the charts is difficult, because while resizing one border, it is shown at a variable and arbitrary distance from where it is while not resizing. In the screenshot is portrayed the moment when I just clicked on the lower handle to resize the graph, but had not moved yet. It seems like Calc wanted to resize the graph to be bigger by 3~4 pixels, (maybe to align to the lower cell, which is what I would had wanted to obtain). When I released the handle with the mouse button, without moving the handle in the meantime, the graph went back to the original size (did not resize bigger by 3~4 px, as Calc let me think it would with the preview). The same also happens if I actually drag the handle (I mean, the offset is maintained; if I resize to a certain height, the result will be 3~4 px shorter than what I expected from the preview). This happens with anchor set either to "to page" or "to cell", but not for every imported chart. Difficult to reproduce: While writing the report, I could only reproduce the issue with the one graph in the screenshot ("Acceleration vs. sine", the first one in sheet2 "calcoli"); but I recall having the same issue with all of the graphs in sheet1 "Misure" while I was editing the document for the first times. This doesn't happen when copying the graph to a Writer document and trying to resize. May not be related, but the doc-file is the same of https://bugs.documentfoundation.org/show_bug.cgi?id=117254
Created attachment 141656 [details] Screenshot of wrong resize preview, while resizing This screenshot required some tricks to obtain. It shows the moment when I started resizing using the lower handle on the chart. I had not moved yet, so the inner line is the original size of the chart and the outer (lower) line is the preview of how big the chart should be after the resize. After taking the screenshot, without moving the mouse, I released the left button. The new size of the chart was exactly the same as before (like the upper, inner line) and not as promised by the preview (the lower, outer line, which is the preview) The text appears blurred because the original and the resize-preview are laid one on the other, and they have different sizes
Bisected (on Windows) to https://cgit.freedesktop.org/libreoffice/core/commit/?id=5991304ede33b112b7700b2b9f0e18f6c523a0e8 commit 5991304ede33b112b7700b2b9f0e18f6c523a0e8 (patch) tree d5170d519e30b970a8d35911e5f6d25db53ec5fb parent e4364376b32c58edc0eaba4c587abe7de0eb9987 (diff) LOK - Calc: charts are misplaced We need to update the transformation primitive wrapping the chart when the grid offset is changed. Change-Id: I42179fdc7cc806c5757a125881f08279767ccbcc Reviewed-on: https://gerrit.libreoffice.org/36255 Adding Marco to CC
So I have investigated a little bit on Linux (I have no Windows build available for poking with it). If I revert commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=5991304ede33b112b7700b2b9f0e18f6c523a0e8 the chart is aligned to the bottom of row 31, while a blue filled gap area appears at row 13 (see screenshot). If I resize any row, the blue gap disappears, and the chart is aligned at the top of row 13 as it would be without reverting commit 5991304. At this point if I perform the same steps described by Lorenzo Chiola, I can see exactly the same issue he reported (both in 5.3 and in master branch). So except there is something Windows specific I would say that the problem is independent from commit 5991304.
Created attachment 142274 [details] A screenshot of the just opened sample sheet with commit 5991304 reverted
Ok, let's put it back to auction.
Dear Lorenzo Chiola, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Lorenzo Chiola, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug