|
Small zero offset in bar chart |
Posted by Andreas on Apr-04-2011 23:29 |
|
We observe a slight shift from the zero line in our bar chart. The bars cross the zero line.
We use this chart (in SVG format) to display it in a pdf.
So, though the shift seems to be small, we receive noticeable effects in our pdf's.
See a magnified screen shot. Note that also the gray zero line has a one pixel shift from the '0' label.
Here is the code:
double[] data0 = { 0.040, 0.341, 0.599, 1.034, 5, 0, 0, 4.547 };
double[] data1 = { 0.015, 0.543, 1.034, 2.792, 1.703, 0, 0, 0.096 };
double[] data2 = { 0.130, 0.203, 0.375, 5, 1.786, 0, 0, 2.269 };
XYChart c = new XYChart(400, 140);
c.yAxis().setMargin(8, 8);
c.yAxis().setLinearScale(-1, 5);
c.enableVectorOutput();
c.setPlotArea(20, 20, 288, 85, Chart.Transparent, Chart.Transparent);
BarLayer layer = c.addBarLayer2(Chart.Side, 1);
layer.setBorderColor(Chart.Transparent);
layer.addDataSet(data0, 0xE96610, "#1");
layer.addDataSet(data1, 0x9FAA00, "#2");
layer.addDataSet(data2, 0x728FB2, "#3");
viewer.Image = c.makeImage();
|
Re: Small zero offset in bar chart |
Posted by Peter Kwan on Apr-05-2011 01:12 |
|
Hi Andreas,
Actually, I cannot see any shift at all. The zero grid line is aligned exactly to the bottom of the back side of the bar.
Note that you are drawing a 3D bar chart (the 3D depth parameter is set to 1). In a 3D bar chart, the grid line is at the back of the plot area, and is aligned to the back surface of the bar (not the front surface). I have attached a 3D bar chart with a bigger 3D depth so you may see more clearly.
If your intention is to draw a 2D bar chart instead, please set the 3D depth to 0, or just rmove this parameter when you called addBarLayer2.
Hope this scan help.
Regards
Peter Kwan
|
Re: Small zero offset in bar chart |
Posted by Andreas on Apr-05-2011 20:24 |
|
Peter,
you are right.I changed the 3D state to a 'flat' chart.
See the attached image.
The bottom of the bars still sticks out one pixel downwards
(see updated screenshot)
|
Re: Small zero offset in bar chart |
Posted by Peter Kwan on Apr-06-2011 02:13 |
|
Hi Andreas,
We apologize very much for this problem.
Are you using an odd number as the plot area height? We are aware of this problem if the plot area height is an odd number. To work around the problem, you may try to use an even number as the plot area height.
Please let me know if this can solve the problem.
Regards
Peter Kwan |
Re: Small zero offset in bar chart |
Posted by Andreas on Apr-07-2011 16:52 |
|
Peter,
seems the reason for this fault is a canvas height with an odd number of pixels.
We will adjust this.
When we can expect this bug to be fixed?
Andreas
(Thank you for your great support btw) |
Re: Small zero offset in bar chart |
Posted by Peter Kwan on Apr-07-2011 23:49 |
|
Hi Andreas,
We plan to fix this bug in ChartDirector Ver 6. Unluckily, we cannot commit on a firm release date at the moment.
Regards
Peter Kwan |
Re: Small zero offset in bar chart |
Posted by Michael on Jul-02-2012 22:54 |
|
Hi Peter,
we still waiting to get this issue fixed. When do you think we could expect a solution? Attached I added a similar problem with rounding
|
Re: Small zero offset in bar chart |
Posted by Peter Kwan on Jul-03-2012 06:38 |
|
Hi Michael,
For the 1-pixel inconsistency in drawing the bars when the y axis is bi-polar (contains both positive and negative data), have you tried to set the plot area height to an even number to work around the problem?
I remembered I had received emails from your company about a similar issue, but in that case it seems the bars were offsetted by a few pixels, and the error also occurs for horizontal bars. (Because the image attachment in the email was not of the original size, and the SVG might be manipulated, so it is hard to know what was the original error.) If the bars are offseted by more than 1 pixel, or if the error occurs for horizontal bars, it may not be related to the error mentioned in this thread, but is due to another issue.
I also remembered I had sent a patch to someone in your company. Have you tried the patch and does it solve the problem? (It shiould solve the problem if the problem is really the one mentioned in this thread.)
In your last message, you have attached the SVG output of the chart. One thing I noticed is that the "stroke-width" is set to 0.35. I have the impression that ChartDirector can only output integer stroke-width. (There is no API in ChartDirector that can accept non-integer line width.) Is it possible the SVG output from ChartDirector is further manipulated by your code (eg. to adjust the "stroke-width") before being displayed?
If the stroke-width is in fact manipulated to become 0.35, this can explain the more than 1-pixel error in the bars. We thought the error was more than 1 pixel as it was several times the size of the line width, which we assumed was 1 pixel. If the thinnest line was actually less than 1 pixel, then the actual bar error may be less than expected.
I have not tested myself, but adjusted the stroke-width may actually contribute to the error. ChartDirector may create the bar with an implied stroke width of 1 unit as the bar border. If the grid line stroke width is less than 1 unit, the bar border may extend beyond the grid line, and it will look like the bar "overshoots" the grid. This may explain why the error appears even for horizontal bars.
For the issue you mentioned about the x coordinates between the data points, currently, in ChartDirector, the data point coordinates are snapped to integers. So if there are 100 data points distributed on a 450 pixels wide plot area, it is possible some points will be 5 pixels apart, while some points will be 4 pixels apart. Such +/- 0.5 pixel errors usually are hard to notice. In your case, as it is in SVG, you can scale it bigger or smaller. If you scale it several times bigger, the errors may become noticible.
(You may notice that the x and y coordinates of the line always ends at 0.5 instead of at integer positions. It is because in SVG, the coordinate of a pixel refers to the top-left corner of the pixel, while internally in ChartDirector, it refers to the center of the pixel. So an offset of 0.5 is added for compensation.)
If my guess is correct (that the stroke-width is manipulated to be 0.35 pixels, and that the chart is intended to scale several times bigger for display), to solve the problem, you may consider not to manipulate the SVG output. Instead, you can create the SVG using the original intended display size or bigger, and scale it smaller. For example, if the chart is created 3 times the current size (use 3 times the width and height when creating the chart), then it would not be necessary to adjust the stroke-width at all. The chart will look the same as your current chart (when displayed in the same size), except the errors will become non-existent or not noticible.
Regards
Peter Kwan |
Re: Small zero offset in bar chart |
Posted by Michael on Jul-03-2012 17:29 |
|
Hi Peter,
I created a sample to illustrate the issue
XYChart c = new XYChart
(
200,
200,
16777215
);
c.enableVectorOutput();
c.setAntiAlias(true, Chart.AutoAntiAlias);
PlotArea pa = c.setPlotArea
(
0,
0,
200,
200,
-1,
-1,
Chart.Transparent,
-131072,
-131071
);
pa.setGridWidth(1, 1);
//xAxis
c.xAxis().setLabels(new string[] { "", " ", " ", " ", " ", " ", " ", " ", " " });
//yAxis
c.yAxis().setColors(Chart.Transparent, Chart.Transparent);
double[] data = { 13, 8, 6, 11, 8, 9, 5, 8, 7, 12 };
List<LineLayer> lineLayers = new List<LineLayer>();
LineLayer ll = c.addLineLayer(data, -131070);
ll.setLineWidth(1);
lineLayers.Add(ll);
c.layoutAxes();
return c.makeChart2(5); // SVG
you see that the vertical lines differ in width
x1 diff
22.5
44.5 -22
67.5 -23
89.5 -22
111.5 -22
133.5 -22
156.5 -23
178.5 -22
If you look in polyline node, you are using 3 decimals, for all other values only 1. I think this results in the difference.
We had issues with the fixed dll you sent to us. (see ChartDirectorDiff.png).
ChartDirectorPerfromanceChart shows a sample how we use the charts. We need to allign a data table below the chart.
|
Re: Small zero offset in bar chart |
Posted by Peter Kwan on Jul-04-2012 00:28 |
|
Hi Micahel,
For the "vertical lines differ in width", I assume you mean the spacing between the vertical lines differ, which is normal. The line width is always 1 pixel and is the same for all lines, which is also normal.
I have tried your code. It does not produce any visible output (the use of the colors -131072 and -131071 seems problematic). I changed it to black (0x000000), and I obtained the attached chart. I have attached the SVG, as well as the image I see if it is viewed using its natural size.
Although the spacing between the vertical lines are not exactly the same, my opinion is that it is hard to notice. Also, the line widths are exactly the same for all vertical lines, and all of them is 1 pixel wide.
The reason why it is normal that the spacing between the vertical lines should differ is because the vertical lines need to be rounded to integer pixel coordinates. If we do not round them to integer coordinates, then some lines may by chance may have integer coordinates, and some lines by chance have non-integer coordinates. For lines that have non-integer coordinates, they will be spread between two pixels due to anti-alias, and they will look thicker compared to the lines that have integer coordinates. Also, the color of the anti-aliased line will look different. (If the line color is black, the anti-aliased line will look grey in color.)
If you look at your ChartDirectorPerformanceChart.png (which I assume is not generated by ChartDirector), you can see the vertical grid lines are in fact inconsistent. The grid lines for 2009 is sharp and is very black. In contrast, the grid line for the 2007 looks thicker and is grey, not black. ChartDirector is currently designed to avoid this by "grid fitting" vertical and horizontal the lines. If you look at the grid lines in the "test.png" I attached or in the ChartDirectorDiff.png, you can see the grid lines are always sharp, of exactly the same color, and very consistent.
The lines in the line layer (the polyline in the SVG output) in general are neither vertical nor horizontal, and so they must be anti-aliased in any case, and so do not need to be grid fitted. That's why their coordinates has 3 decimals.
For the ChartDirectorPerformanceChart.png, do you mean you would like to generate a similar chart using ChartDirector? If both the line layer and the table below are generated by ChartDirector, the vertical lines should match, as ChartDirector will grid fitted the vertical lines in the same way. However, if you are using ChartDirector for the chart, and try to put a table created by a different program underneath it, the vertical lines may not match exactly. For example, the ChartDirector lines may all have the same line width of 1 pixel, the same color, and look sharper, while in your current chart, the vertical lines have variable line widths (1 to 2 pixels due to anti-alias) and variable colors (from grey to black). So for consistency, I suggest you use the same program to create the entire SVG image (the line chart with the table below).
If you must use a different program to generate the table, one work around I can think of is to adjust the width of the table (which is equal to the width of the plot area) so that it is an exact multiple of the number of "horizontal segments" in your chart. For example, in your ChartDirectorPerformanceChart.png, there are currently 6 segments for the years 2007, 2008, 2009, 2010, 2011, 06/12. If the table width (which is equal to the width of the plot area) is an exact multiple of 6, then the coordinates of the vertical grid lines should be exact integers and both ChartDirector and the table generating program should agree on the exact coordinates of the grid lines.
Regards
Peter Kwan
|
|