Created attachment 108476 [details] A calc sheet reproducing the issue Problem description: When you make Calc generate a diagram of type "Line" from 2 data sets (one for the X axis, the other for the Y axis), Calc sorts the dataset values, based on X-axis values (ascending order), before displaying them in the diagram. For example, if the X-axis values are dates, these dates are sorted so that the diagram shows value in chronological order. This is a nice feature, incidentally. However, when you double-click on the diagram and let the mouse on one of the curve points, a tip shows up, but this tip gives wrong information if the X-axis values in the source range needed sorting before being displayed the diagram (actually, information given is not erratic, it just relates to the wrong cell in the source cell range). How to reproduce the issue: - Open the attached Calc document. It contains 4 sheets with the very same data, sorted in a different way each; every sheet also contains a diagram of type "Line" showing up these data graphically. Note that all 4 diagrams are strictly identical, since data are identical (though they are sorted with different criteria every time). - Select any of the "... -- KO" sheet. - Double-click on the diagram. - Let the mouse over any point of the curve, et look at the tip info. Every sheet in the attached Calc document also gives 3 examples of points, with their expected and actual tip texts. Expected result: The tip over any point in the diagram should take into account the fact that values were sorted when generating the diagram. Which means that the 1st point on the left in the diagram may not be the value of the 1st cell in the source cell range; the 11th point from the left in the diagram may not be the value of the 11th cell in the source cell range; and the last point on the right in the diagram may not be the value of the last cell in the source cell range. Note: As a reference, I also added a sheet in the attached spreadsheet, named "Ascending Date -- OK", which shows that point tips are OK when the data are already sorted in ascending order in the source cell range.
The type "Line" does not use first column as abscissa, it uses it as labels. You can check that if you open the dialog Data Range. You will see that for your chart you do not have a data range for X values, only for Y values. In fact the X values are given by the line numbers. If you want a chart with 2 data ranges, one for the X values and one for the Y values, you must use the type XY. Best regards. JBF
@ Jean-Baptiste Faure I agree with your note. However, if you look at the attached spreadsheet, you will see that tip information over the points in the curve does not match these points. That's the point of this issue: no matter the type of diagram, the tip over a given point should give information on this particular point, and not on a different point located somewhere else in the curve.
I disagree, you give to the labels a meaning that is not intended by Chart. The first label is only the first label, whatever is written on the label. Best regards. JBF
Sorry, but what is the purpose of displaying a pop-up tip when the mouse goes over a particular point of the curve if the shown tip gives information, not on that point, but on a point, which is completely different and located somewhere else? If I may say so, I'd say it makes the tip... simply pointless.
I can reproduce this in LO 5.0.1 (on Arch Linux). The issue appears even when using an XY (scatter) chart type, as JBF suggested using instead. It seems as if on rendering the chart, the X-Y values are laid out on the chart in some unspecified order, while the line will simply connect the points from leftmost to rightmost, discarding the order in the data series. When the mouse hovers on a point, the label it references is then relative to the first point in the line, instead of being the actual index in the data series of the point. I would also expect the tooltip to refer to the correct point, as per the original reporter said.
I can reproduce this in LO 5.1.0.3 (on Windows 6.1).
I can also reproduce this in LO 5.2.1.2 (on Windows 6.1).
I can also reproduce this in LO 5.3.0.3 (on Windows 6.1).
I can also reproduce this in LO 5.4.1.2_x64 (on Windows 6.19).
I can still reproduce this in LO 6.0.0.3_x64 (on Windows 10.0).
** Please read this message in its entirety before responding ** 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 http://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
I can still reproduce this in LO 6.2.0.3_x64 and various LO 6.1.x (_x64) versions (on Windows 10.0).
Amendment to my previous comment: below are some additional information on the LO 6.2.0 version, against which I tested the bug again: Version: 6.2.0.3 (x64) Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62 Threads CPU : 4; OS : Windows 10.0; UI Render : default; VCL: win; Locale : fr-FR (fr_FR); Langue IHM : fr-FR Calc: threaded
I can still reproduce this with LO 6.3. Please find below detailed LO version information: Version: 6.3.0.4 (x64) Build ID: 057fc023c990d676a43019934386b85b21a9ee99 Threads CPU : 4; OS : Windows 10.0; UI Render : par défaut; VCL: win; Locale : fr-FR (fr_FR); Langue IHM : fr-FR Calc: threaded
I can still reproduce this with LibreOffice 6.4. Please find below detailed LO version information: Version : 6.4.1.2 (x64) Build ID : 4d224e95b98b138af42a64d84056446d09082932 Threads CPU : 4; OS : Windows 10.0 Build 18363; UI Render : par défaut; VCL: win; Locale : fr-FR (fr_FR); Langue IHM : fr-FR Calc: threaded
I can still reproduce this with LibreOffice 7.0. Please find below detailed LO version information: Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: fr-FR (fr_FR); Langue IHM : fr-FR Calc: threaded
I can still reproduce this with LibreOffice 7.1. Please find below detailed LO version information: Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can still reproduce this with LibreOffice 7.2. The pop-up tip over any point of the graph still gives wrong data information, namely data information on a wrong point of the graph, as soon as X-axis-graph data are sorted in any order different from the ascending one. Please find below detailed LO version information: Version: 7.2.0.4 (x64) / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can still reproduce this with LibreOffice 7.3. The pop-up tip over any point of the graph still gives wrong data information, namely data information on a wrong point of the graph, as soon as X-axis-graph data are sorted in any order different from the ascending one. Please find below detailed LO version information: Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can still reproduce this with LibreOffice 7.4. The pop-up tip over any point of the graph still gives wrong data information, namely data information on a wrong point of the graph, as soon as X-axis-graph data are sorted in any order different from the ascending one. The bug description includes a small Calc sheet, which reproduces the bug. Please find below detailed LO version information: Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can still reproduce this bug with LibreOffice 7.5 : When the mouse is over a point of the graph, the data information given by the pop-up tip is wrong and does not relate to the right point in the graph, as soon as X-axis-graph data are sorted in any order different from the ascending one. A small Calc sheet, which reproduces the bug, is attached to this bug description. Please find below the detailed LO version information: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
I can still reproduce this bug with LibreOffice 7.6 : When the mouse is over a point of the graph, the tooltip that pops up does not refer to this point but a point elsewhere in the graph, as soon as X-axis-graph data are not sorted in the ascending order. One would expect the tooltip to refer to the correct point. A small Calc sheet, which reproduces the bug, is attached to this bug description. Please find below the detailed LO version information: Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
Thank you Olivier for re-testing so consistently over the last... 9 years!! I can also still reproduce the issue in a recent trunk build. I think it has the same root cause as bug 37407, but because: - your chart type here is "line" with a Date type for the X axis scale, whereas the other report focuses on X-Y scatterplots sorted by X - and the axis scale type "Date" was not available in OOo 3.3, but started in 3.4 ...I think we can keep them separate. But please also follow that other report if you are interested. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f95c3994f0b6a82a3bc2ddfb68822b74479ae185 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
*** Bug 101509 has been marked as a duplicate of this bug. ***
I can still reproduce this bug with LibreOffice 24.2. Please find below the detailed LO version information: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded