[Bioperl-l] GD/SVG (was: new to the group)

[Todd Harris]

Hi Ronan -

GD::SVG is now on CPAN!  My first CPAN contrib - please have a look.  I'll
be releasing a new version today or tomorrow where I solved the setBrush and
gdBrushed methods internally.

> I see we're both running into the same problems. In particular the font issue
> (this seems to be due to the way perl handles xs objects? it returns an
> object that sometimes seems to bet treated like a string.

I've worked around this by

1) exporting the same font methods as GD;
Each of these methods contains hard-coded info on height and weight that
mimic GDs fonts, then returns a generic font object (in my case
GD::SVG::Font).

2) The GD::SVG::Font object
This package creates generic formatting common to all the fonts, implements
the height() and width() methods, and establishes GDs oo approach to fonts
(ie GD::Font->Large).  In the oo case, these methods simply call the
exported method, a bizarre circularity which works fine.

This looks to be quite similar to how you've handled it as well.

> Maybe someone in bioperl has advice about how to grab the GD namespace without
> forsaking the use of the GD methods?

For the most part I've been forsaking GD's methods and I've found very few
reasons to actually use GD's methods directly (sorry Lincoln, no offense!).
This is best illustrated when considering the colorAllocate and rgb methods.
GD's colorAllocate method returns a color index.  The rgb($index) method
returns the rgb triplet.  Neither of these methods are really useful to
generating SVG - colorAllocate just needs to return a stringified rgb
triplet; the rgb method can just parse the index and return the triplet that
way.

I took a look at SVG::GD and see that you are maintaining an internal
version of the GD image. I started doing the same thinking I could take
advantage of some of GD's color manipulation methods but think it is
overkill for my purposes.

But with regards to the use of these GD wrapper modules, I'm not sure that
maintaining both a GD::Image and the SVG image concurrently is the best
idea.  For example, many scripts (especially CGIs) will predominantly
generate raster images via GD.  And with Bio::Graphics and Gbrowse, the SVG
images from these scripts can be *substantially* larger than their raster
brethren. It's useless to generate these images in SVG when the intent is
only to produce a raster image.

Instead of enabling raster/svg decision to be made at the time of output, I
ask that the user make a decision on what their output should be before
"use".  Coupled with an eval (ie eval "use $package"), this can also be
dynamically established at runtime.  No biggie, really.

That said, I think we can easily maintain an internal representation of the
GD::Image - just have to avoid all the exported functions and call them
directly.

todd

> Pls. see private re. collaboration. I'm all for it.
> 
> I've installed your module and will run around in it a bit to get a better
> world view of how you use it and of how much similarity there is between
> SVG::GD and GD::SVG.
> 
> For now, feel free to take anything out of SVG::GD for your own use.
> 
> Ronan
> 
> On Tuesday 18 November 2003 17:40, Todd Harris wrote:
>> Hi Ronan -
>> 
>> Ha, great minds!, right This looks pretty good.  I've been working on a
>> similar module that works exactly the same and maps almost all functions
>> into SVG output (using your SVG module).  I've placed this in the GD
>> namespace as GD::SVG since that seems to more closely represent the intent
>> of the module.
>> 
>> You can check out a preliminary version of my module at
>> http://toddot.net/GD-SVG/GD-SVG.0.01.tgz
>> 
>> Docs:
>> http://toddot.net/GD-SVG/gd-svg.html
>> 
>> And some very preliminary test images based on Bio::Graphics and some
>> simple test scripts:
>> http://toddot.net/GD-SVG/test.png
>> http://toddot.net/GD-SVG/test.svg
>> http://toddot.net/GD-SVG/biographics-dynamic_glyphs.png
>> http://toddot.net/GD-SVG/biographics-dynamic_glyphs.svg
>> http://toddot.net/GD-SVG/biographics-lots.png
>> http://toddot.net/GD-SVG/biographics-lots.svg
>> 
>> These images are a little out-of-date.  I've fixed many of the formatting
>> discrepancies already.
>> 
>> I've already added support for GD::SVG into bioperl, so perhaps we should
>> coordinate our efforts on the GD::SVG (or SVG::GD module). In particualr,
>> there are a number of kludges that need to be implemented (regarding font
>> sizes, positions, etc) to correctly map GD<->SVG output (particularly in
>> regards to Bio::Graphics.
>> 
>> Thanks,
>> 
>> todd
>> 
>> On Thu, 13 Nov 2003, Ronan Oger wrote:
>>> Hi,
>>> 
>>> My name is Ronan Oger, I am the lead developer of the SVG module.
>>> 
>>> One of the focuses of my current work is SVG::GD, a wrapper for the GD
>>> module to provide SVG (vector) output instead of raster.
>>> 
>>> http://www.w3.org/Graphics/SVG/
>>> http://www.w3.org/TR/SVG
>>> 
>>> I've been doing some tests with GD and GD derivatives, and since bioperl
>>> is a fairly heavy user of GD, I have been testing around some bioperl
>>> code to see how it works.
>>> 
>>> There are some real issues in the SVG::GD at this point, but several
>>> people are working on it and progress is being made.
>>> 
>>> Clearly this is not production code at this stage. In particular, font
>>> support is still very poor, and font positions are still broken.
>>> 
>>> However, here is a bioperl-specific sample (you need an SVG-compliant
>>> browser, such as IE with Adobe or Corel's SVG viewers installed.
>>> 
>>> A png and its svg friend taken from a bio-related example on the net
>>> ------------------------------------
>>> http://www.roasp.com/2003/11/13/
>>> 
>>> More prolific example comparisons
>>> http://www.roasp.com/2003/11/11/
>>> 
>>> The SVG::GD module (version 0.07):
>>> http://www.roasp.com/2003/11/11/SVG-GD-0.07.tar.gz
>>> (This module has a dependency on SVG, which is on CPAN)
>>> When it ripens, the module will live on CPAN.
>>> 
>>> I'd appreciate some feedback, issues, etc. In particular, relating to the
>>> module's usability.
>>> 
>>> All the best,
>>> 
>>> Ronan
>>> 
>>> --
>>> Ronan Oger
>>> http://www.roasp.com
>>> Serverside SVG Portal
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at portal.open-bio.org
>>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>> 
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at portal.open-bio.org
>> http://portal.open-bio.org/mailman/listinfo/bioperl-l