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: 16863
Status: resolved
Priority: 0/
Queue: GDGraph
People
Owner: bwarfield [...] cpan.org
Requestors: etimme [...] gmail.com
janne [...] janne.nu
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 1.4305
Fixed in: 1.4308
Attachments
sample95.png

History Show all quoted text
  Mon Jan 02 06:42:41 2006 Guest - Ticket created
Subject: No / misplaced y-ticks for two_axes
When drawing y-ticks the axis number is submitted as dataset number. This has to be adjusted by adding 1, otherwise the pixels will be calculated to way off the canvas. GDGraph-1.4305/Graph/axestype.pm 1056c1056 < my ($x, $y) = $self->val_to_pixel(0, $value, $axis); --- Show quoted text
> my ($x, $y) = $self->val_to_pixel(0, $value, $axis + 1);
This is perl, v5.8.7 built for i386-linux Linux pc1183 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 Intel(R) Pentium(R) 4 CPU 2.66GHz unknown GNU/Linux / Jan Sundberg
  Mon Jan 02 09:16:52 2006 Guest - Correspondence added
From: janne [...] janne.nu
[guest - Mon Jan 2 06:42:41 2006]: It's more complicated than that: - when calculating ticks for y2 one has to be sure min & max comes from $self->y_min[2] and $self->y_max[2] and *not* go via use_axis! One solution is to supply negative argument when calculating ticks for y2: GDGraph-1.4305/Graph/axestype.pm 1056c1056 < my ($x, $y) = $self->val_to_pixel(0, $value, $axis); --- Show quoted text
> my ($x, $y) = $self->val_to_pixel(0, $value, -$axis);
1883c1883,1885 < ? $self->{y_min}[$self->{use_axis}[$i-1]] --- Show quoted text
> ? $i < 0 ? > $self->{y_min}[-$i] > : $self->{y_min}[$self->{use_axis}[$i-1]]
1887c1889,1891 < ? $self->{y_max}[$self->{use_axis}[$i-1]] --- Show quoted text
> ? $i < 0 > ? $self->{y_max}[-$i] > : $self->{y_max}[$self->{use_axis}[$i-1]]
Show quoted text
> When drawing y-ticks the axis number is submitted as dataset number. > This has to be adjusted by adding 1, otherwise the pixels will be > calculated to way off the canvas. > > GDGraph-1.4305/Graph/axestype.pm > 1056c1056 > < my ($x, $y) = $self->val_to_pixel(0, $value, $axis); > ---
> > my ($x, $y) = $self->val_to_pixel(0, $value, $axis + 1);
> > This is perl, v5.8.7 built for i386-linux > > Linux pc1183 2.6.12-12mdk #1 Fri Sep 9 18:15:22 CEST 2005 i686 > Intel(R) Pentium(R) 4 CPU 2.66GHz unknown GNU/Linux > > / Jan Sundberg
  Thu Jan 19 00:04:02 2006 bwarfield [...] cpan.org - Correspondence added
First off, I'm sorry I didn't reply to this already—I hadn't spotted it, and I didn't get an e-mail about it. Could you possibly provide some code (modifying sample95.pl might be easiest) that demonstrates the precise nature of the bug? I'm not fully understanding it from your description, and the few things I've tried by way of attempting to break the tick-mark code haven't produced any problems that seem to match (though I observe that range calculations are broken, which may be closely related). On Mon Jan 02 09:16:52 2006, guest wrote: Show quoted text
> [guest - Mon Jan 2 06:42:41 2006]: > > It's more complicated than that: > > - when calculating ticks for y2 one has to be sure min & max comes from > $self->y_min[2] and $self->y_max[2] and *not* go via use_axis! > > One solution is to supply negative argument when calculating ticks for y2: > > GDGraph-1.4305/Graph/axestype.pm > 1056c1056 > < my ($x, $y) = $self->val_to_pixel(0, $value, $axis); > ---
> > my ($x, $y) = $self->val_to_pixel(0, $value, -$axis);
> 1883c1883,1885 > < ? $self->{y_min}[$self->{use_axis}[$i-1]] > ---
> > ? $i < 0 ? > > $self->{y_min}[-$i] > > : $self->{y_min}[$self->{use_axis}[$i-1]]
> 1887c1889,1891 > < ? $self->{y_max}[$self->{use_axis}[$i-1]] > ---
> > ? $i < 0 > > ? $self->{y_max}[-$i] > > : $self->{y_max}[$self->{use_axis}[$i-1]]
> >
  Thu Jan 19 00:04:03 2006 The RT System itself - Status changed from 'new' to 'open'
  Thu Jan 19 04:00:46 2006 janne [...] janne.nu - Correspondence added
I haven't able to produce an example where the misplaced ticks occur. When I tried (by 100-folding the second and third dataset, i.e. y2 axis, in sample95.pl) I got: [5] Maximum for y2 too small at sample95.pl line 91 at sample95.pl line 91. which can be related to my other bug report (16880), I'll have to check later. Regarding this one, I'm simply saying that in draw_y_ticks_v, iteration is performed over the two axes in order to process both axes but the axis number supplied to val_to_pixel is interpreted as a dataset number! There has to be a way to tell val_to_pixel to use a specific axis, and not to go via use_axis all the time, since you want to process the two axes, not the two first datasets. I chose the simple way indicating an axis number with a negative number and a dataset number with a positive. On Thu Jan 19 00:04:02 2006, BWARFIELD wrote: Show quoted text
> First off, I'm sorry I didn't reply to this already—I hadn't spotted > it, and I didn't get an e-mail > about it. Could you possibly provide some code (modifying sample95.pl > might be easiest) > that demonstrates the precise nature of the bug? I'm not fully > understanding it from your > description, and the few things I've tried by way of attempting to > break the tick-mark code > haven't produced any problems that seem to match (though I observe > that range calculations > are broken, which may be closely related). > > > On Mon Jan 02 09:16:52 2006, guest wrote:
> > [guest - Mon Jan 2 06:42:41 2006]: > > > > It's more complicated than that: > > > > - when calculating ticks for y2 one has to be sure min & max comes
> from
> > $self->y_min[2] and $self->y_max[2] and *not* go via use_axis! > > > > One solution is to supply negative argument when calculating ticks
> for y2:
> > > > GDGraph-1.4305/Graph/axestype.pm > > 1056c1056 > > < my ($x, $y) = $self->val_to_pixel(0, $value, $axis); > > ---
> > > my ($x, $y) = $self->val_to_pixel(0, $value, -$axis);
> > 1883c1883,1885 > > < ? $self->{y_min}[$self->{use_axis}[$i-1]] > > ---
> > > ? $i < 0 ? > > > $self->{y_min}[-$i] > > > : $self->{y_min}[$self->{use_axis}[$i-1]]
> > 1887c1889,1891 > > < ? $self->{y_max}[$self->{use_axis}[$i-1]] > > ---
> > > ? $i < 0 > > > ? $self->{y_max}[-$i] > > > : $self->{y_max}[$self->{use_axis}[$i-1]]
> > > >
  Sat Feb 11 18:28:58 2006 bwarfield [...] cpan.org - Taken
  Mon May 01 12:43:43 2006 Guest - Ticket #19012: Ticket created
Subject: problem with y2 tick scale labeling with two_axes / use_axis
y2 tick scale labeling issue with GD::Graph 1.4307. Data plotted against the y2 axis will scale correctly in the graph, however labels will not be plotted correctly. The y2max value will be obeyed, but it seems to draw values relative to the y1 axis. IE y1max is 40, y2max is 8, y_tick_number is 8, y_label_skip is 2, the y2 labels will draw 2, 4, 6, 8, and these will be visually below our first line (which is y1 axis's 10), or missing if y2max is larger than y1max. This bug might be related to 16863 "No / misplaced y-ticks for two_axes". To replicate modify sample95.pl as follows: # use_axis => [1, 2, 2], use_axis => [1, 1, 2], Note, [ 1, 2, 1 ] seems to work correctly.
Subject: sample95.png
Download sample95.png
image/png 8.9k
sample95.png
  Mon May 01 17:10:39 2006 Guest - Ticket #19012: Correspondence added
From: etimme [...] gmail.com
Problem is definetly the same as in the previous report mentioned in the original post. Bug is in GD::Graph::axestype.pm draw_y_ticks_h and draw_y_ticks_v and their interaction with val_to_pixel, which expects a dataset as its third parameter. We pass it an "axis", so sometimes it works (when our second data set has an "use_axis" value of 2, like in the examples) and sometimes it does not (when our second data set has an "use_axis" value of 1). I chose to create a new function val_axis_to_pixel that is called only by draw_y_ticks_h and draw_y_ticks_v. I then changed the y_min and y_max calculations as follows : my $y_min = $self->{two_axes} ? $self->{y_min}[$i] : $self->{y_min}[1]; my $y_max = $self->{two_axes} ? $self->{y_max}[$i] : $self->{y_max}[1]; There were no other changes as compared to val_to_pixel. I have not tested the solution posted in the previous bug thread by janne@janne.nu (pass a negative value to val_to_pixel) but it looks like it does the same thing without defining a new function.
  Mon May 01 17:10:41 2006 The RT System itself - Ticket #19012: Status changed from 'new' to 'open'
  Mon May 01 17:15:22 2006 Guest - Correspondence added
From: etimme [...] gmail.com
On Thu Jan 19 04:00:46 2006, janne@janne.nu wrote: Show quoted text
> I haven't able to produce an example where the misplaced ticks occur.
I've posted an example of the bug with a screenshot in bug #19012 with my own explanation. That bug is the same as the one in this thread, and is probably fixed by janne@janne.nu's patch. val_to_pixel should be passed a data set, not an axis, as its third parameter. When we are drawing axes we pass "1" when we are drawing y1, and "2" when we are drawing y2. If your second data set has an "use_axis" value of "2" (as in all examples) this bug will not show up.
  Sun May 14 23:53:40 2006 bwarfield [...] cpan.org - Ticket #19012: Merged into ticket #16863
  Sun May 14 23:53:40 2006 bwarfield [...] cpan.org - Merged into ticket #16863
  Mon May 15 22:54:37 2006 bwarfield [...] cpan.org - Correspondence added
Well, an ideal solution to this would probably be changing val_to_pixel so that it expects (and all of the calls to it so that it *gets*) an axis number instead of a dataset number. On the other hand, that would require roughly 23 code changes, and the negative-number approach takes only three, so for now I'll use that one (since it's all internal, it's theoretically possible I'll change it to work the other way at some future point, if it seems like a good idea). Thanks very much to you both!
  Mon May 15 22:54:39 2006 bwarfield [...] cpan.org - Status changed from 'open' to 'resolved'
  Thu May 18 15:00:53 2006 bwarfield [...] cpan.org - Fixed in 1.4308 added