Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Chart-Clicker CPAN distribution.

Report information
The Basics
Id: 73898
Status: open
Priority: 0/
Queue: Chart-Clicker
People
Owner: Nobody in particular
Requestors: thomas.wolf [...] uni-jena.de
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Wed Jan 11 08:38:56 2012 thomas.wolf [...] uni-jena.de - Ticket created
Subject: Problem with axis label: whitespace in string
Date: Wed, 11 Jan 2012 14:38:45 +0100
To: bug-Chart-Clicker [...] rt.cpan.org
From: Thomas Wolf <thomas.wolf [...] uni-jena.de>
Hi, I am using Perl 5.10.1 on Ubuntu 10.04 64 bit and Chart::Clicker 2.76. Setting a label for the chart itself (title->textbox) and a name for the series works well. Setting a label for the range-axis (y-axis) only works with strings _without_ whitespaces. Setting a label _with_ whitespaces makes Chart:Clicker to print each part of the string, seperated by a whitespace, over each other (starting at the same position). The label of the domain-axis (x-axis) behaves normal. This problem seems to be related to "Bug #53528 for Chart-Clicker: Problem with tick labels, spaces & angles". There the labels of the ticks are broken if they contain a whitespace. ### use Chart::Clicker; my $chart = Chart::Clicker->new(); #$chart->get_context("default")->range_axis->label("example_label"); # ok $chart->get_context("default")->range_axis->label("example label"); # NOT ok my $series = Chart::Clicker::Data::Series->new(keys=>[1, 2, 3], values=>[1, 2, 3]); my $dataset = Chart::Clicker::Data::DataSet->new(series=>[$series]); $chart->add_to_datasets($dataset); $chart->write_output("labels.png"); ### Regards, Thomas
  Mon Feb 13 12:33:21 2012 GWS [...] cpan.org - Correspondence added
Same problem here (Windows 7, Perl 5.14, Chart::Clicker 2.76).
  Mon Feb 13 12:33:23 2012 The RT System itself - Status changed from 'new' to 'open'
  Mon Feb 13 18:55:34 2012 GWS [...] cpan.org - Correspondence added
In the meantime I did some debugging. There semm to be at least three problems in Graphics::Primitive::Driver::Cairo::TextLayout. (I didn't check ...GD::TextLayout, which may have similar problems.) These together seem to explain the strange behaviour of labels containg spaces. * TextLayout->layout uses Text::Flow to wrap any text into some predetermined width. This predetermined width, however, seems to be much too small. In my case, the width of the component reported for a y axis label is just 19. It seems that the method does not take into account that the y axis label will be shown rotated by 90 degrees. Instead of taking the component's width, its height should be taken as the reference width for text wrapping. The height of that component is, btw, 60, which would be quite enough for the label without any wrapping. --> Fixing seems not to be trivial (at least to me), because arbitrary text rotations might be involved. * Next, Text::Flow breaks the label into smaller pieces. This creates two more problems: Firstly, an empty line seems to be prepended (which will mess up subsequent calculations); secondly, the whitespace on which the label was split is not removed, so each resulting line comes out longer than it should be. --> Fixing this shouldn't be difficult; it would suffice to change the split statement to my @lines = ($p =~ /\n/) ? split(/[\t ]*\n/, $p) : $p; * Finally, the foreach loop that is supposed to set the chunks of text is too simple to do its task. It does calculate the bounding boxes for the chunks alright, but it forgets to update the origin of these boxes. The result is that all the little boxes end up at the same place, thus overwriting each other. T Furthermore, each of these operations just add both width and height to the containing component. Really, however, the width should be the max (not the sum) of the individual chunk widths, and only the height should be the sum of heights. -->
  Mon Feb 13 19:02:32 2012 GWS [...] cpan.org - Correspondence added
[Sorry. Story continues here.] In fact, after each chunk, the y coordinate of the origin for the next chunk should be incremented. Unfortunately, again, this seems no trivial task, because arbitrary text rotations need to be taken into account. I do not understand enough of the whole ensemble of modules to be able to say whether all this is, in fact, easy to handle because there are neatly stacked series of containers, each with their own litle coordinate system, or whether one would need to jump back and forth between a component's coordinate system and that of its parent (which may be substantially different). In any case, maybe this gives you, Cory, a grip on the problem.