Created attachment 48535 [details] A minimal spreadsheet demonstrating the problem 1. Set up 3 columns, 3 rows in the top left corner like this: Label X Y A 1 1 B 0 1 2. Create an X-Y chart. Create two data series, A and B. a. For series A: Name=$A$2, X-Values=$B$2, Y-Values=$C$2, Labels=$A$2 a. For series B: Name=$A$3, X-Values=$B$3, Y-Values=$C$3, Labels=$A$3 3. For both series, select "Show data labels." 4. For both series, select "Format data labels," and on the data tab, un-check "Show value as number" and check "Show category". Expected: Data points are labeled A and B. Actual: Data points are labeled A and A.
Reproduced on LibreOffice 3.4 340m1(Build:12) in KDE on OpenSuse for Linux. Downloaded the attachment. If I try to change the label by: 1. Right click chart -> Data Ranges 2. Select "B" from under Data Series 3. Change the Data Labels cell to $A$3, then the Data Labels cell for series "A" changes as well. Seems like the two are linked together.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
(In reply to comment #2) > [This is an automated message.] > This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it > started right out as NEW without ever being explicitly confirmed. The bug is > changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back > to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. > Details on how to test the 3.5.0 beta1 can be found at: > http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 > > more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html Tested in 3.5.0 rc3 Bug still persists. The cause of this bug is that the "Data Labels" field in a chart is a set globally for all data ranges in a chart. To remedy this, it would have to be possible to set different data labels for each data series. In many scientific applications it is essential to be able to control how all data points on an X-Y graph are labeled, so this would be a very useful feature
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Attached document demonstrates wrong behaviour. But problem not reproducible from scratch in 3.3.4 and 3.6.1. Therefore, possible, problem is inside of file. Or I am doing something wrong.
I am marking this as WORKSFORME. I see correct labels when opening this with LibreOffice 3.6.3.2 as well as in Excel. I am running this on Linux, if this is still an issue in Windows please reopen as UNCONFIRMED and I'll get someone with Windows to take a look at it. Closing it just because it's so old that it's likely been fixed + I can't imagine the code in this section being dependent on operating system. Thanks for your patience.
I can confirm this bug on libo 4.0.2.2 (on win7). The labels show A, A, instead of A,B.
At version 4.0.2.2: Confirmed. Data label is common for ALL data series at XY chart.
reproducible on LO 4.0.3.3 (Win7 32bit)
Created attachment 105474 [details] Example showing multi and single series arrangement in row and column-based layout. I am not convinced this report is a bug. https://help.libreoffice.org/Chart/Chart_Type_XY That help page states: > An XY chart in its basic form is based on one data series consisting of a > name, a list of x‑values, and a list of y‑values. Each value pair (x|y) is > shown as a point in a coordinate system. The name of the data series is > associated with the y‑values and shown in the legend. According to the help page, this type of chart only supports a single-series arrangement. It is also not clear from the provided example, whether the Labels "A" and "B" are single points in different series or different points in a single series. I have attached a clearer example, showing some options, given series A and B and points A1/A2 and B1/B2 in each series respectively. It still needs to be determined whether multiple series are supported in this type of chart. Generally a line chart is used where multiple series are required.
Per comment 13, status set to NEEDINFO.
I discovered the problem because I had a need to represent multiple series on an x-y plot. I was able to determine that it doesn't work even though the UI seems like it would offer that functionality. I suggest that there is a bug either in the functionality or the UI, but that the optimal solution is to improve the functionality to support multiple series. I would have a look at this code myself, but I fear it would take 10 hours just to get my bearings.
(In reply to comment #15) > I discovered the problem because I had a need to represent multiple series > on an x-y plot. I was able to determine that it doesn't work even though > the UI seems like it would offer that functionality. > > I suggest that there is a bug either in the functionality or the UI, but > that the optimal solution is to improve the functionality to support > multiple series. I agree. Attachment 105474 [details] merely illustrates this more clearly. The XY Scatter chart type is effectively a more strict subset of the Line chart type (in terms of dialogs presented in the wizard). It is possible to use the XY Scatter chart type to plot multiple series, but the data needs to be in Line (category for X-axis; data series for Y-axes) arrangement, rather than XY Scatter (X coord for X-axis; Y coord for Y-axis) arrangement. It seems the chart wizard or something in code does not treat the XY Scatter chart type as strictly as it could. I find this confusing as it inhibits, rather than assists, clear thinking about the data and arrangement. Hopefully we can get some clarity on this.
The 'bug' is presently set as NEEDINFO and as of version 4.4.2.2. I would categorise this behaviour as a bug as so many people expect the behaviour desrcibed from the originally stated case, myself included. Another reason to call it a bug is that if 'Show value as number' and 'Show category' are both enabled, the value data shown does not restart but the category does, making the two adjacent pieces of data in the label incongruent. Simply making the help documentation state that this is a known limitation is not a solution, it is an awkward side-step of the problem. It can't be expected that someone need to restructure a whole worksheet simply because of a limitation in charting. The category data simply needs to be made one-per series rather than one-per chart. I cannot see what this change would conflict with.
In accordance with comment 13, comment 15, and comment 16 I am adding "NeedsDevEval" tag to whiteboard as it is not clear to me whether this report is: - an enhancement request (to improve chart wizard to either be clearer about the restriction or support multiple series); - a bug (if the XY Scatter chart is supposed to support multiple series); - supported by ODF. Status set to NEW.
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
*** Bug 98997 has been marked as a duplicate of this bug. ***
Thanks to raak for linking this bug to my new (duplicate) one. I looked for duplicates but hadn't obviously looked back to 2012! With regards to comment 18 I would argue that this issue is a bug in that xy scatter graphs should be able to deal with multiple series labels -especially considering that you can make multiple series in calc. If the bug cannot be rectified soon then the ui needs updating as a stopgap so people do not experience this shortfall without realising the output from calc is incorrect. E.g. only allowing label input for 1 series. This is not a solution however and I would argue that the bug needs fixing.
Hi Alex, Quick point. > > If the bug cannot be rectified soon then the ui needs updating as a stopgap > so people do not experience this shortfall without realising the output from > calc is incorrect. E.g. only allowing label input for 1 series. This is not > a solution however and I would argue that the bug needs fixing. This isn't how an open source project works. There is no "needs fixing" - every bug needs fixing, the thing is that a volunteer must take an interest in fixing it. The options are always the same: 1) Fix it yourself (open source means that you can do just that); 2) Find someone to fix it; 3) Pay for a fix - almost always too expensive for an individual person 4) Wait Even if the UI "needs updating" it'll take a volunteer to tackle that.
Created attachment 124800 [details] Two data series with different labels As workaround you can define each data series on the whole x-range and leave the y cells empty for those x-values, which do not belong to the series.
Thanks to Regina for the workaround (comment 23). I am also among those considering this a bug: a) It is possible to show multiple data series in an XY chart (as shown in Regina's workaround). So it is counter-intuitive that only a single series of labels can be chosen. b) The UI allows the user to select labels that APPEAR to be tied to the individual series (along with the choice of X-data and Y-data). But if a set of data labels is selected for one data series, then IN REALITY this selection applies to all data series. c) 'Show value as number' uses the individual series, while 'Show category' uses the single series of data labels, which together gives incongruent labels (see comment 17). I am aware that bugs are only fixed, if somebody chooses to fix them. So far my own contribution is only in trying to give useful bug reports. Kudos to everybody actually FIXING the bugs! (Using LO version 5.2.4.2)
** 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
This bug is still present in v 5.4.4.2, build 5.4.4.2-3.fc27, 8 threads on Linux 4.14, VCL: gtk3, en-us.UTF-8, Calc: group. Attachment 105474 [details] shows the problem very clearly.
Dear Jim Scarborough, 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
Not implemented in Version: 7.0.0.2 (x64) Build ID: c01aa64b6c3d89ebe5fe69c28c7adb24eb85249c CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: CL Investigation needed, whether this needs ODF extension and whether such feature is needed for interoperability with MS Office.
An ODF extension would be needed. The labels are written in a <chart:categories> element and that is a child of the <chart:axis> element and not of a <chart:series> element. The <chart:series> element has only the <chart:domain> child element for the x-values and the <chart:values-cell-range-address> child element for the y-values.
Created attachment 182187 [details] Clarification and demo of a workaround (In reply to Regina Henschel from comment #29) > An ODF extension would be needed. The labels are written in a > <chart:categories> element and that is a child of the <chart:axis> element > and not of a <chart:series> element. The <chart:series> element has only the > <chart:domain> child element for the x-values and the > <chart:values-cell-range-address> child element for the y-values. But ( I only refer to X-Y-Scatter, because IO very rarely use different types.): 1. The data source for the labels is described as "Data labels" in the dialog (UI), and can be chosen per series. 2. Trying to assign a different labels range for a different series is neither blocked nor provoking an alert. However, the new range is applied to all the series witzhout further notice. == This is clearly misleading the user, and insofar a bug. === 3. The dialog also offers (by default) to use the values as labels. This may be rarly sensible, but seems to tell me that functionally the ODF representation of the cahjrt and the UI as well as the API don't talk the same language. === A different kind of bug? === 4. On the other hand the actual implementation may have a way to use "hidden series" as sources for er4xplicit labels NOT being categories withot violating the needs concerning the saving to an ODF. Do YOU know? I will attach a not quite miniomal example wherte labels from extra ranges are implemented by user code. It may not help concerning prpobable conflicts with ODF stanbdards, but it surely can show what I would expect a reasonable solution to be capable of. Generally a solution saving info about source-ranges for labels per series wolud be clear, useful and allowe for simplification of the 'Format Data Labels' dialog (which isn't exactly about formattiong).
*** Bug 155409 has been marked as a duplicate of this bug. ***
Duplicate bug 155409 offers a good example of needing independent data label ranges for two series: attachment 187400 [details]
Affects all OSs; same in OOo 3.3 -> inherited.
*** Bug 159806 has been marked as a duplicate of this bug. ***