Skip Menu |

This queue is for tickets about the GDGraph CPAN distribution.

Maintainer(s)' notes

There are plenty of good ideas of what people can do published here on the queue. Turning a patch from the tracker into a pull request is not one of them. In order to get maintainers' attention way more quickier, PR should have at least a sample included. We know it's hard to test images generating software, but it doesn't mean we can not test numbers produced by intermediate algorithms used to generate these images, so either a test or a sample.

Report information
The Basics
Id: 44791
Status: open
Priority: 0/
Queue: GDGraph

People
Owner: Nobody in particular
Requestors: mr140 [...] ntrs.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: GD::Graph pie chart non-3D bug with simple example
Date: Fri, 3 Apr 2009 16:14:08 -0500
To: bug-GDGraph [...] rt.cpan.org
From: Michael Raffety <mr140 [...] ntrs.com>
Download PieTest2D-bad.png
application/octet-stream 1.8k

Message body not shown because it is not plain text.

Message body is not shown because sender requested not to inline it.

Download PieTest3D-good.png
application/octet-stream 2k

Message body not shown because it is not plain text.

First, GD::Graph is awesome, I use it extensively! Second, there's a rather interesting bug that only occurs when you do a 2D (non-3D) pie chart. The dclrs choices don't work quite right, it's wrong. Here's the code, and attached are two example outputs. This is with ActiveState Perl 5.8.9 build 825 and GD::Graph 1.44 on Windows XP. Thank you! Show quoted text
_______________________________________________________________________________ Michael Raffety | Application Performance & Troubleshooting | Availability & Monitoring 840 S. Canal Street, Chicago, IL 60607 | phone 312-557-2216 | cell 630-261-1888 | mr140@ntrs.com CONFIDENTIALITY NOTICE: This communication is confidential, may be privileged and is meant only for the intended recipient. If you are not the intended recipient, please notify the sender ASAP and delete this message from your system. IRS CIRCULAR 230 NOTICE: To the extent that this message or any attachment concerns tax matters, it is not intended to be used and cannot be used by a taxpayer for the purpose of avoiding penalties that may be imposed by law. For more information about this notice, see http://www.northerntrust.com/circular230
Subject: GD::Graph pie chart color bug with simple example
On Fri Apr 03 17:16:55 2009, mr140@ntrs.com wrote: Show quoted text
> First, GD::Graph is awesome, I use it extensively! > > Second, there's a rather interesting bug that only occurs when you do > a 2D > (non-3D) pie chart. The dclrs choices don't work quite right, it's > wrong. > Here's the code, and attached are two example outputs. > > > > This is with ActiveState Perl 5.8.9 build 825 and GD::Graph 1.44 on > Windows XP. > > Thank you! > >
I see the same thing. Your data set has 3 points: ['Green','Amber', 'Red'], [ 1, 0, 2 ] It seems to be related to the 0 size of your amber/yellow data point. If I change it, it fixes the colors: 0 - problem occurs. Wrong colors are used in chart. 0.001 - non-zero, but still too small to be visible, problem occurs. 0.01 - just barely visible, no problem. Interestingly, the green point always changes to yellow, the 3rd point always seems to be correctly red. I'm running Fedora 10, perl 5.10.0, GD::Graph::VERSION 1.44 so it appears to be unrelated to platform. I came looking for this bug because I see wrong colors occasionally in the 3-D graph, so I don't think it is a 2-D vs 3-D problem unless there are two very similar bugs. I havent been able to narrow it down to a test case, though.
I believe that draw_data in pie.pm is the culprit. When $slice_angle is close to 0, calling fillToBorder can escape and fill the last slice. To fix it, I tried calculating when the slice is only one pixel across and skip filling in that case. pixels = w/2 * sin Approximating sin = angle in radians for small angles gives pixels = w * ang * pi/360 diff pie.pm.orig pie.pm 276a277,279 Show quoted text
> # Don't fill slices less than 1 pixel wide > next if ($slice_angle * $self->{w} * 0.0087) < 1; >
This worked for values of amber in the above failing case ranging from 0 to 0.01. Reducing the constant makes the failure less likely, but makes unfilled pixels more likely to appear. The failure is more objectionable than a narrow unfilled slice, though.
After trying various values for the constant, I settled on this: 19a20,22 Show quoted text
> # Heuristic value smaller than pi/360 > use constant SLIVER => 0.005; >
276a280,282 Show quoted text
> # Don't fill slices less than 1 pixel wide > next if ($slice_angle * $self->{w} * SLIVER) < 1; >
With this value for SLIVER I don't see the failure in my code or the test case above. However, there are too many variables such as radius, position on the circle, aliasing, and the algorithm used in fillToBorder so I can't be sure that there are not still failing cases. Setting the Amber data point to 0.007 shows the worst case unfilled sliver. my @data=( ['Green','Amber', 'Red'], [ 1, 0.007, 2 ] );
Subject: New GD::Graph co-maintainer and new release on CPAN
Hello, You recieved this message as you filed a bug report or feature request against GD::Graph module on CPAN. My name is Ruslan and I'm new co-maintainer of the module. I've updated the module to 1.45 with doc changes and released it to CPAN. See distribution status [1]. I have TODO list for several releases, so if your ticket was a patch then turning it into a nice pull request may expedite inclusion :) [1] http://search.cpan.org/~ruz/GDGraph-1.45/Graph.pm#DISTRIBUTION_STATUS -- Best regards, Ruslan.