[Bioperl-l] bioperl graphics

[Jonathan Crabtree]

Hi Todd-

Todd Harris wrote:

>>On 3/1/04 9:02 AM, Jonathan Crabtree wrote:
>>    
>>
>
>Hi Jason - 
>
>Well, that's great news!  I couldn't remember if I had added colorResolve to
>GD::SVG.  Whoops!  As you can see, it's something of a kludge, but I'm glad
>to hear that it works for you.
>  
>

Not at all; it works just fine, and I think GD::SVG is a great way to 
generate SVG documents from GD-aware code.  The only problem I see with 
the current implementation of colorResolve() is that it doesn't try to 
determine whether the requested color has already been "allocated". 
 This breaks the documented API, although in a rather minor way; it's 
unlikely that anyone would write code that relies on subsequent 
identical calls to colorResolve() returning the same color index.  It 
also means that the 'colors_added' array will be larger than it needs 
to, and that colorsTotal() will return a misleading result, though again 
these are both very minor issues.  I just noticed that the man page does 
state that colorResolve is unimplemented, so perhaps this is what caused 
the confusion about the method's disposition:

     $index = $image->colorResolve(red,green,blue)
           NOT IMPLEMENTED
 

>Regarding Lincoln's suggestion of copying images, correct me if I'm wrong,
>but I interpreted that to mean copying the images OUTSIDE of
>Bio::Graphics::Panel.  That is, create your Panel, fetch it, then paste it
>where appropriate into a new GD::Image with the appropriate dimensions. To
>avoid the method-overriding aspects of GD::SVG, this might need to be done
>within a separate package or eval block.
>

Yes, I think my understanding of Lincoln's suggestion is the same as 
yours.  I'm not too familiar with SVG, but it seems as though it might 
be possible to do a pure SVG implementation of copy() using nothing more 
than a clipping path (if only a portion of the source image is to be 
copied), a transform, and an appropriate grouping of the source 
elements.  However, even if GD::SVG::Image supported copy(), I still 
think I'd lean towards keeping my current multi-Panel implementation, 
using only a single GD::Image or GD::SVG::Image, and relying on passing 
the same image object to the gd() method of multiple panels.  The 
copying seems like an unnecessary step when the current 
Bio::Graphics::Panel API supports reusing a single image object (and the 
corresponding code can be made to support it with a 1-line change.)

>I'm planning a significant upgrade to GD::SVG over the next few weeks that
>should 1) enable parallel creation of a GD object; 2) make it compatible
>with more current GD methods, and 3) make it more robust for future methods.
>  
>

That sounds great.  Thanks for the feedback,

Jonathan