I am running RT 3.0.4 with the latest statistics package from
http://www.tzi.de/~hollow/Statistics3.tgz.
On all the stats pages I just get the broken image icon. When I try to
view the image directly Mozilla claims that the content type it returned
as text/html and displays the bytes of the PNG as text. I don’t know
too much about RT yet to really debug this myself but I tried a few
things. I modified one of the Chart files and changed the line that
said $r->header_out(“image/$format”) to
$r->content_type(“image/$format”). This time Mozilla got the correct
content type, but complained that the image was corrupt and couldn’t be
displayed. I tweaked around with a few more things, but couldn’t get
anywhere. I saved the image to disk and opened it with a binary editor
and noticed that there is a line feed (0x0a) in the first byte. If I
delete that byte I can load the image. I am not sure where it is coming
from though, so I can’t fix it.
I can’t imagine everyone that is using this had to change this line and
weak a bunch of stuff so, am I missing something trivial here? Are
there updates or patches to the above version that I am missing?
Thanks,
Jake
Jacob S. Barrett
Chief Technology Officer
PogoZone LLC
email: jbarrett@pogozone.com
web: www.pogozone.com
voice: 360-676-8772
fax: 360-733-3941
address: 114 W. Magnolia Street Suite 417
Bellingham, Washington 98225
I can’t imagine everyone that is using this had to change this line and
weak a bunch of stuff so, am I missing something trivial here? Are
there updates or patches to the above version that I am missing?
I have posted a patch to Harald that addresses this problem, as well as
providing a complete i18n string extraction. Its headers read:Date: Fri, 25 Jul 2003 19:09:44 +0800
From: Autrijus Tang autrijus@autrijus.org
Subject: Re: [rt-devel] New Release of the Statistics package
To: Harald Wagener hwagener@hamburg.fcb.com
Cc: rt-devel@lists.fsck.com
Message-ID: 20030725110944.GA20939@not.autrijus.org
I’d appreciate if Harald can take a look at it, if as you claimed that
it hadn’t been merged yet. 
Thanks,
/Autrijus/
Thanks. I applied the patch that I extracted from that email. Some of
the lines got rejected, so I had to patch them up myself. Unfortunately
I am still seeing the line feed in the first byte of the image. Any
ideas. Here is what my patched CallsQueueDay/Elements/Chart looks like:
% $m->print($graph->plot(@data)->$format());
% $m->abort();
<&|/l, $#data+1&>[1] Elements</&>:
% for (0…$#data) {
<% $data[$] %>
% }
<%INIT>
use GD::Graph::lines;
my @data;
my $graph = GD::Graph::lines->new(400,300);
$graph->set(export_format => “png”);
push @data, [split /,/ , $ARGS{x_labels}];
push @data, [split /,/ , $ARGS{data1}];
push @data, [split /,/ , $ARGS{data2}];
push @data, [split /,/ , $ARGS{data3}];
my $format = $graph->export_format;
$r->content_type(“image/$format”);
</%INIT>
<%ARGS>
</%ARGS>
Thanks,
Jake
Jacob S. Barrett
Chief Technology Officer
PogoZone LLC
email: jbarrett@pogozone.com
web: www.pogozone.com
voice: 360-676-8772
fax: 360-733-3941
address: 114 W. Magnolia Street Suite 417
Bellingham, Washington 98225
I can’t imagine everyone that is using this had to change this line
and
weak a bunch of stuff so, am I missing something trivial here? Are
there updates or patches to the above version that I am missing?
I have posted a patch to Harald that addresses this problem, as well as
providing a complete i18n string extraction. Its headers read:
Hello,
been on vacation for a week. I will look at this as soon as I have
caught up with issues at work. I was not aware there was a bug fix in
Your patch Autrijus.
Regards,
Harald