UNRESOLVED BUGS

? 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>)

