Created attachment 40341 [details] Example EIA data with charts, to show inability to pick a subset It appears that Calc does not support the idea of displaying a subset of axis labels for an arbitrary label set. Say for year 1950 through 2000, I have nuclear and renewable energy data (that's three column headers "Year", "Nuke", "Renew", and three columns of data) and I want to view the stacked area plot for each year. Currently, I can: - select the data to be charted, but not the year column. Then explicitly tell LO the axis range and interval. - Select all three columns, check the "first column as label" box, and let LO figure out it's own range based on the width of the graph and axis label font size. The first method is a lot more work than it needs to be, and also does not handle tic labels that are not numerical. The second is a "let it go" option rather than actually fixing the issue. (Attached an example ODS file with some EIA data, but it's difficult to example this lack of feature without a dev trying it out.)
I should add that MS Excel 2007 appears to have a notion of axis label intervals that (almost) covers the use case.
I'm taking this for the time being.
Created attachment 40342 [details] Excel version of same data, this time with proper axis-tic intervals. As requested by Koshida, here's an Excel 2007 version of the same data.
Created attachment 40343 [details] Screenshot of Excel version of same data, with proper axis-tic intervals. And, in case the xlsx file doesn't work, here's a screenshot of same.
One other tidbit, Excel doesn't seem to give an option to start the tic label interval at an arbitrary label. Which is why, for instance, the screenshot starts at 1949, not 1950. It would be nice to have the ability to start /labeling/ at any arbitrary tic, yet show all the data.
This is a Calc/Chart issue, therefore changed the 'Component' field accordingly. If I understand correctly, this is an enhancement request, therefore changing the 'Importance' field accordingly. Please change back if I missed something ...
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
(In reply to QA Administrators from comment #7) > Your bug was confirmed at least 1 year ago and has not had any activity on > it for over a year. Your bug is still set to NEW which means that it is open > and confirmed. It would be nice to have the bug confirmed on a newer version > than the version reported in the original report to know that the bug is > still present -- sometimes a bug is inadvertently fixed over time and just > never closed. Sigh. I recognize that LibO is largely a volunteer-based community, but this style of interaction doesn't give bug reporters much incentive to provide further bug reports. That is, I believe the initial post and requested follow-up information -- all within the first hour after initial reporting in 2010 --*clearly* describe the problem / enhancement request: if bugs/enhancement requests like this can "time-out" without any thought-process or ownership from QA administrators or devs, then it is similarly not worth my time to write the corresponding prose in the first place. Annoyance aside, yes, this bug report/feature request is still a valid issue to the best of my understanding of LibO 4.3 in Ubuntu 64-bit. > Lastly, good bug reports help tremendously in making the process go > smoother, please always provide reproducible steps (even if it seems easy) > and attach any and all relevant material This particular bug report is not "one of the weak ones" (the issue -- no method to display arbitrary axis labels -- is stated in the first sentence, and there are three supporting documents -- a LibO-created spreadsheet, an Excel-created version of same, and an image highlighting the proper behavior), exacerbating my earlier point about bug reporter frustration. If the report were weaker, I might better understand, but it's not and thus my grievance with this LibO QA practice.
Same in: Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1fd42472e2b1a2169d56e62ef11aa7ee1f7815e7 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded