1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
UNRESOLVED BUGS
- 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>)
|
