IssioDev

There is an inconsistency between the plot borders on a bar2d and column2d chart which has become apparent with the 3.18.0 release. With a column2d chart the bottom border of each column didn't exist because there was a x-axis With a bar2d chart the left border of each bar is present, even if there is a y-axis This also doesn't occur with a stacked 2d bar chart., This jsFiddle demonstrates the issue. The column chart is fine, the bar chart is not. https://jsfiddle.net/1d27n9ha/3/

When using an mscombi2d chart with y-axis values: 'AxisMinValue: 0, yAxisMaxValue: someOddValue The zero value for the y-axis is not displayed. If the yAxisMaxValue is even then it is displayed. In fact this happens whenever the scale is not a multiple of the gap, ie: min: 0, max 13. This is new to 3.13.x

I can confirm that this is now fixed with v3.13.4. Note: When I went to download from the Product Update Center it listed the latest version as v3.13.3-sr.1, but the downloaded files were actually v3.13.4

When using an mscombi2d chart with y-axis values: 'AxisMinValue: 0, yAxisMaxValue: someOddValue The zero value for the y-axis is not displayed. If the yAxisMaxValue is even then it is displayed. In fact this happens whenever the scale is not a multiple of the gap, ie: min: 0, max 13. This is new to 3.13.x

Still not fixed in 3.13.3, I was so hopeful. Oh well, setting the yAxisMaxValue seems to be the thing that invokes the bug with adjustDiv: 1, if you let the chart work out the yAxisMaxValue from the data it seems fine.

Thanks. I look forward to testing the fix.

You see this is where we have a differing view. You see with 3.12.x and every version before that it works just fine. See this jsFiddle (https://jsfiddle.net/f87az9ec/4/). Also this isn't a bug in the automatic adjustment of the divisional lines, it's a bug in the labeling of the minimum y-axis value which is somehow linked to the setting of adjustDiv in v3.13.x Either way, it's a bug. "may not work properly" is the exact wording for something (ie: a bug) that used to work (3.12.x and older), doesn't work anymore (3.13.x and newer). Nevertheless, we have moved on, turned off adjustDiv to work around the bug and have written our own automatic divisional line algorithm as the FusionCharts version now has unwanted side-effects in v3.13 and newer. Personally I really don't see how this is so hard to fix, especially as it used to work. Anyone else who suffers the same issue when upgrading to 3.13, let me know and I'll send you the code for our algorithm so you can work around the bug. Maybe I'll post it on StackOverflow so others can work around the bug.

I think you are saving that you broke it in 3.13 and here is the workaround. You know this works in all versions prior to 3.13 don't you? All in all I can work with this, it is disappointing though that the "automatic internal divisional line algorithm" has broken but I can turn it off and replicate the work that your algorithm is doing myself. Displaying the 0 on the y-baseline shouldn't really be a function of the "automatic internal divisional line algorithm" which really is the point isn't it.

3.13.2-sr1 seems a little better that 3.12.2 in this regard but still has problems we "odd" values of y-axis. "Even" values always work just fine.

Here you go.... https://jsfiddle.net/f87az9ec/ Note that there is no 0K on the scale if you set the "yAxisMaxvalue": 11 whereas there is when you set it to 10. Only seems to happen with odd values, not even values. v3.12 didn't have this problem but 3.13 does.

Here you go.... https://jsfiddle.net/f87az9ec/ Note that there is no 0K on the scale if you set the "yAxisMaxvalue": 11 whereas there is when you set it to 10. Only seems to happen with odd values, not even values. v3.12 didn't have this problem but 3.13 does.

Can somebody approve this post please.