Created attachment 108476 [details]
A calc sheet reproducing the issue
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.
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 188.8.131.52 (on Windows 6.1).
I can also reproduce this in LO 184.108.40.206 (on Windows 6.1).
I can also reproduce this in LO 220.127.116.11 (on Windows 6.1).
I can also reproduce this in LO 18.104.22.168_x64 (on Windows 6.19).
I can still reproduce this in LO 22.214.171.124_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!
I can still reproduce this in LO 126.96.36.199_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: 188.8.131.52 (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
I can still reproduce this with LO 6.3.
Please find below detailed LO version information:
Version: 184.108.40.206 (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