Description: If you make a graph with X axis starting at 10, and ending at 1000, the minor grid lines should (and will) be drawn at: 10 20 30 40 50 60 70 80 90 100 200 300 400 500 600 700 800 900 1000 If you make a graph with X axis starting at 20, and ending at 2000, the minor grid lines should be drawn at: 20 30 40 50 60 70 80 90 100 200 300 400 500 600 700 800 900 1000 2000 However, if you try the second case in LibreOffice Calc, it draws them with the same spacing as the first case, just with different labels, so the grid lines are actually at mostly useless numbers: 20 40 60 80 100 120 140 160 180 200 400 600 800 1000 1200 1400 1600 1800 2000 Instead, the lines should always fall on multiples of 10, regardless of starting point, not on arbitrary numbers. Steps to Reproduce: 1. Create a graph 2. Insert minor grid lines 3. Set spacing to logarithmic 4. Set starting point at anything other than a power of 10 Actual Results: See above Expected Results: See above Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.2.2 (x64) Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: CL
Created attachment 160012 [details] Examples of good and bad log scales
Please attach a sample file.
Created attachment 160050 [details] Example of spreadsheet with log scale graph You mean an ODS file?
(In reply to 7qia0tp02 from comment #3) > Created attachment 160050 [details] > Example of spreadsheet with log scale graph > > You mean an ODS file? Yes, thanks for the example. I can confirm the described behavior using the example in 6.2.8: Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded So Calc indeed draws minor grid lines like the "bad" one in attachment 160012 [details], however I don't use logrithmatic scale graphs enough to confirm that everyone should draw it like the "good" one.
(In reply to Ming Hua from comment #4) > however I don't use logrithmatic scale graphs enough to > confirm that everyone should draw it like the "good" one. Well, I use them frequently and the major ticks are always on the powers of the base, even if the labels are elsewhere. 99% of the time it's base 10, with the major ticks on the powers of 10 and minor ticks on the next significant digits. Occasionally it's base 2 or some other thing (https://probablydance.com/2016/12/02/investigating-radix-sort/ for example) but the major ticks are still on the powers of the base. There's no reason to put them anywhere else, it just makes the chart much harder to read.
(In reply to 7qia0tp02 from comment #5) > Well, I use them frequently and the major ticks are always on the powers of > the base, even if the labels are elsewhere. 99% of the time it's base 10, > with the major ticks on the powers of 10 and minor ticks on the next > significant digits. Occasionally it's base 2 or some other thing > (https://probablydance.com/2016/12/02/investigating-radix-sort/ for example) > but the major ticks are still on the powers of the base. There's no > reason to put them anywhere else, it just makes the chart much harder to > read. I didn't realize that the major grid lines are different from the convention as well, until now. Your analysis makes sense, let's ping the Chart meta bug and see if we can attract any developer into this discussion. There is also bug 62924 that have discussions about the same topic, though it seems there are multiple issues in the comments there (labels for minor grids, default values for major and minor grids, upcoming ODF standard, etc.), so I'm leaving this as a seperate bug for now.
More attributes for better describing the grid position will be introduced in ODF 1.4, see https://issues.oasis-open.org/browse/OFFICE-3936 So whoever will working on this, should consider it.
Dear 7qia0tp02, 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
No, it hasn't magically fixed itself since the bug report was submitted. Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
No, it hasn't magically fixed itself since the bug report was submitted.
Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded 🙄