BUGS

UNRESOLVED BUGS

- from rt.cpan.org

Subject: two_axis graphs ranges poorly chosen  
  
When you let GD::Graph dynamically pick ranges for a 2-axis graph, you
can get a very large number of ticks and a range choice that makes
rather little sense. If you go to http://www.perlmonks.org/index.pl?node_id=138068 and
hit "d/l code" at the bottom of the page you will find a patch that fixes
this.

see two_axis_range.patch

- from rt.cpan.org


Subject: GD::Graph to fails when plotting graphs flatlined at '0.00'  
  
  
Hi, I think i've discovered a small 'bug' in GD::Graph::axestype If i try and plot a graph that is flatlined at  '0.00'  (quotes important), i get the
error: Illegal division by zero at /home/shahsag/my_tree/links/cpan/lib/GD/Graph/axestype.pm
line 1176 I've tracked the problem down to a line of code right at the begining of the
_best_ends method in axestype.pm where you try and specfically deal with the case
where $max and $min are equal and at zero. Unfortunately this code doesn't seem to cover the case where $max = '0.00' and $min =
'0.00'. I attach a small test script with some comments that might make things a little
clearer. Would you be willing to produce a fix for this and release a new version of GD::Graph
onto CPAN? The version of perl i am using is 5.6.1.
The version of GD::Graph is 1.33.
The OSes that i've seen this on are: Solaris 2.6 and 8 on SPARC fyi: The reason why i can't easily switch from using '0.00' to 0.00 is that i'm
getting the graph data from another cpan module (StatsView::Graph) and it feels like
a change to axestype.pm might be the neatest solution. Sagar Download (untitled) 1k
  
  
#!/usr/bin/perl
use strict;
use warnings;
use GD::Graph::lines; 
my($graph, $image, $margin, @data, $filename); 
$filename = "/tmp/gd_graph_axis_bug.png";
$margin = 5;
$graph = GD::Graph::lines::->new(700 ,450); 

$graph->set(
    x_label           => 'Time (Local Time)',
    y_label           => 'Values',
    title             => "Hello World",
    line_width        => 1,
    box_axis          => 0,
    x_label_skip      =>  30,     #changed
    x_label_position  => 1/2,
    x_labels_vertical => 1,
    bgclr             => "white",
    transparent       => 0,
    t_margin          => $margin,
    b_margin          => $margin,
    l_margin          => $margin,
    r_margin          => $margin,
   ); 

@data = (
 [ '1', '2', '3', '4', '5', ],
 [ '0.00', '0.00', '0.00', '0.00', '0.00', ],
);
#
# If you change all the '0.00' to  0.00 then there is no error
# but you do get a graph where the Y axis starts from a negative
# number (i suppose so that the line doesn't co-incide with the x
# axis)
#
# See end of script for an explanation of the cause
$image = eval {
$graph->plot(\@data);
};
if($@ or !defined $image) {
die("PLOT FAILED: $@\n");
} 
print "READY TO WRITE IMAGE: $filename\n"; 
open(IMG, ">", $filename) or die("Unable to open $filename : $!");
binmode IMG;
print IMG $image->png;
close IMG; 

# GD::Graph::axestype   : line #1149-1150
#
# if $min = 0.00, and $max = 0.00, executing the following code
#CODE:($min, $max) = ($min) ? ($min * 0.5, $min * 1.5) : (-1,1)
#CODE:if ($max == $min);
#
# results in  $min = -1, $max = 1
#
#
# if $min = '0.00', and $max = '0.00', executing the following code
#CODE:($min, $max) = ($min) ? ($min * 0.5, $min * 1.5) : (-1,1)
#CODE:if ($max == $min);
#
# results in  $min = 0, $max = 0
#
# Which later causes a division by zero error!!
#
#
# So essentially the problem is down to the fact that    0.00 and
# '0.00' are the same when you treat them as numbers, but not as
# booleans
#

- From: Eric White <ewhite@ssc.wisc.edu>
  My question concerns the fact that when I create bar graphs
  with GD::Graph and set cumulate = 1 and show_values = 1 the
  values for the "2nd" data set are drawn within the bars for
  their data rather than above the bars (as is the case for the
  "1st" data set).  (I've included a graph that illustrates this
  much better than I can describe it.)

- Reported by Michael Ho (see bug_test/scale_off.pl)
  Heuristics to determine default values for y axis can be terribly
  wrong in certain circumstances.

? mgjv -
  Hotspots stuff needs a lot of thought. Currently linespoints graphs
  will end up with whichever hotspot was drawn last, which is probably
  not what we want. Lines have a hotspot on a line segment, instead of
  on the point of interest. Areas have hotspots in the wrong place.

? mgjv -
  Have not been able to reproduce this, as far as I can tell, $type is
  never tainted inherently. If it is ever tainted, it got tainted in the
  calling program, and should be untainted there.

  report:
  when running in tained mode (-T), I get an error about the $type in
  draw_data_set is insecure in the eval-line. I fixed this "the ugly" way by
  adding a line to tain it within the module:

	sub draw_data_set($$$) # GD::Image, \@data, $ds                         
	{                                                                       
		[...]                                                           
		my $type = $s->{types}->[$ds-1] || $s->{default_type};          
		if ($type =~ /^([a-zA-Z0-9]+)$/) { $type = $1; } else { $type = +""; };

  Reported by Martin Lorensen <mlo@uni2.dk>

+ area chart doesn't do overwrite? Workaround: sum up your data sets, 
  and order them backwards (highest one first). Output graph will look 
  like it's incremental.
  only bar charts do overwrite. Necessary to implement generally?
+ mixed graphs, overwrite = 1 has no effect
  Yolanda Herbert <herbert@odo.edwards.af.mil>

NOT REALLY BUGS

- The whole naming of x_label.*, x_tick.*, x_axis.* is very confused
  and confusing. Hard to fix without breaking backward compatibility.
- overwrite == 2 only makes sense if all the data is either positive,
  or negative
- A positive y_min_value doesn't work with bars or area, bars and area 
  always are set off against 0. Wether this is a bug, or wanted behaviour
  might be a point for discussion. I've decided that it's wanted.
- Do I really need to create the GD object right at the start? And if I
  do, can't I be a bit more clever about allowing people to draw on it
  before plotting the graph?
- init_graph does too much work for pies. Needs to be split up. Very low
  priority.

FIXED IN 1.22
! two_axes only works correctly with negative numbers and zero_axis for
  bars and area graphs.
! Fixed estimation of y_tick_number attribute in axestype::set_max_min
  sub. A lot of code added there.

FIXED IN 1.21
! y_min_value doesn't automatically get adapted for bars and area if 0
  is not included in the range, but only if user sets it. If left to
  figure it out itself, GIFgraph does it right.
! infinite loop when two data sets with only one point, two_axes option,
  and one data set has a negative member
! two_axes doesn't work correctly with negative numbers and zero_axis
! y_max_value doesn't get adapted for bars and area if all negative values
! The order of the determination of minima and maxima, and the calculation
  tick numbers by _best_ends needs to be revaluated.

FIXED IN 1.20

! Spacing of text relative to axes. Became apparent when testing with
  large TTF fonts.
! as I was using GIFgraph, I modified one line which could be a bug in Scott
  Prahl's addings :
  In my package, I  replaced line  631 :
  my $label = $s->{x_values}[$i];
  by
  my $label = $s->{x_labels}[$i];
  Reported by acl <acl@cyberdeck.net>, Mon, 17 May 1999 12:21:42 +0200
! legend text now has its own colour. Previously was drawn in same colour
  as axes. Silly.
! (retrospectively documented) Sometimes, for one graph, the values are
  0 everywhere (for examples for a    disk with no activity) and
  GIFgraph fails with a "Illegal division by zero", check _best_ends
  "Benjamin Yang" <byang@betasphere.com>

FIXED IN 1.11

! _best_ends with (-1,-1) loops infinitely
! for some graphs, numerical X axis ticks are one pixel off

FIXED IN 1.10

! When first value of a dataset is undef for a lines graph, things go 
  wrong.
  (report by Arto Nurmela <arto.nurmela@nmp.nokia.com>)

FIXED IN 1.04

! logo positioning and legends don't work very well together.

FIXED IN 1.03

! When data values are large, and x_min_value is larger than 0, the
  horizontal axis doesn't get drawm correctly. (check zero_axis option)
  (see sample41)
  (problem found after report from jackb@pgw.picker.com)

FIXED IN 1.02

! GIFgraph::Colour::read_rgb() falls over on comment lines.
	(reported: adamm@genomecorp.com)
! GIFgraph::Colour::read_rgb() contains inline my-declaration of $line, 
  breaks perl5.003 
	(reported: Pat Becker <pmb@iss.net>)
! if a colour name doesn't exist, program falls over with a cryptic message
  about some undefined array index.
	(reported: adamm@genomecorp.com)
! x_label_skip doesn't skip ticks. (also added x_all_ticks option)
	(reported: adamm@genomecorp.com)

FIXED IN 1.01

! for loops break in 5.003 because of 'my' scoping (grrrr) 
	(reported: Brian Eitrem <beitrem@digitalriver.com>)
! ticks get drawn in front of the data set 
	(reported: Honza Pazdziora <adelton@informatics.muni.cz>)
! length estimate of y labels needs to be done better
	(reported: Honza Pazdziora <adelton@informatics.muni.cz>)

FIXED IN 1.00

! GIFgraph::colour::sorted_colour_list() syntax error
! GIFgraph::colour pod documentation fixed
! placement of title is centered on gif, not on graph.
! linespoints graph type initialises two GD::Image objects
! 'make test' fails on all tests on win32. binmode() needed.

FIXED IN 0.99

! Cannot use any 'null' values in graphs
	(reported: Lee Khandelwal <lee_khandelwal@il.us.swissbank.com>)

FIXED IN 0.95

! filled markers don't fill correctly when overlapping

FIXED IN 0.94

! area doesn't work with negative numbers
! Right axis doesn't get drawn when box_axis == 0 and two_axes == 1
! Color on front of 3D pies wrong with some data sets
	(reported: by various people)

FIXED IN 0.91

! Segmentation fault for 3d pies where last slice is small
	(reported: Dave Stafford <Dave.Stafford@mpn.cp.philips.com>)