Bug 44546 - EDITING: Y axis scale auto-detection finds much too big maximum value
Summary: EDITING: Y axis scale auto-detection finds much too big maximum value
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
3.5.0 Beta2
Hardware: Other All
: medium normal
Assignee: Kohei Yoshida
URL:
Whiteboard: target:3.5
Keywords: regression
: 44437 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-01-06 13:16 UTC by Michael Meeks
Modified: 2012-01-09 14:13 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
test file (23.38 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-01-06 13:17 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2012-01-06 13:16:29 UTC
Load attached file; select the data range, click 'insert chart'.
Notice the horrible Y scale that is selected - most odd :-) is there some X/Y confusion going on ?
Comment 1 Michael Meeks 2012-01-06 13:17:25 UTC
Created attachment 55225 [details]
test file
Comment 2 Michael Meeks 2012-01-06 13:17:38 UTC
and confirming :-)
Comment 3 Rainer Bielefeld Retired 2012-01-07 01:04:32 UTC
[Reproducible] with Parallel Dev-Installation of  "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978] and reporter's sample, Y-max is "45000" although maximum value is only "5177"

Has already been submitted as "Bug 44437 - FILEOPEN particular .xls shows wrong scale for y-axis", but this report seems to show that it's a more general problem.

It seems that the problem has to do with the x-axis values, the maximum y-axis value would be appropriate for the maximum x-value (format as standard number); but there seem to me additional conditions for the problem. 

Creating a new LINE chart in sample document with 3.4.5 first a lines chart will be shown with y-max 45000 and an x value line above 40000, when you click "first column as label" X-values line disappears and view switches to Y-axis max=6000 

Creating a new LINE chart in sample document with 3.5.0 it starts as in 3.4.5, when you click "first column as label" X-values line disappears as in 3.4.5, but  Y-axis max remains.

With what did the problem start?
[Reproducible] with Server installation of  Master "LOdev 3.5.0beta2+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 22905fb-b605e4f-4c1bcb5]" Win-x86@6- - pull time 2011-12-20 20:59:59)

Here somewhere the problem started Between Beta1 and Beta2?

Worked fine with parallel installation of MinGW Master "LibO-dev 3.5.0 Beta 1 – WIN7 Home Premium (64bit) English UI (Build ID: 8935521-b204871-3e50423-4c1bcb5) (daily/Win-x86@7-MinGW/master/2011-12-13_03.17.52)"
Worked fine with Server installation of MSVC Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [Build ID:  a286353-090bcba-3bf3b94]" Win-x86@6 – 2011-12-02_22:36:35)
Worked fine with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  5d1a991-4cb1bac-ca7e6f5-9125509-ce71330)]" (111109)

@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 4 Rainer Bielefeld Retired 2012-01-07 01:09:17 UTC
*** Bug 44437 has been marked as a duplicate of this bug. ***
Comment 5 Kohei Yoshida 2012-01-07 09:27:13 UTC
Attachment from Bug 44430 which Bug 44437 refers to is located here (just to make it easier to get it without jumping to two other bugs to get to it)

https://bugs.freedesktop.org/attachment.cgi?id=55093
Comment 6 Kohei Yoshida 2012-01-07 09:27:34 UTC
I'll look into it.
Comment 7 Kohei Yoshida 2012-01-07 09:38:27 UTC
Ha ha!  I already know even without looking at the code what we are doing wrong.  We are adding the y values whose x value is identical, for scale estimation.  I added that change to fix the stacked chart scale estimation bug.
Comment 8 Kohei Yoshida 2012-01-09 14:13:13 UTC
Finally fixed!

http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=cbb7814247ad99eac2de0fac207774755bdfc2bd

The correct logic was somewhat more complex than I thought, but hopefully I got it (mostly) correctly.  There may still be some corner cases where it is not optimal, but it's still better than before.

The fix will go into 3.5.0 Beta3.