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

[Ronan Oger]

On Monday 24 November 2003 02:00, you wrote:
> 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.
>

Congradulations, and best of luck with it.

Did you make sure to fill out the README? I noticed it was unread on the prev. 
version.

> > 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).

Right. I found that I could do this in *certain* cases, but that in other 
cases I seemed to be losing the blessing on the object when getting it back. 
Of course this might simply have been my error and may be a red herring.

>
> 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.
>

Yes, thisi s how I did it, But as mentioned previously I still havent got it 
working.

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

Never mind about the above, sorted this out.

> 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.
>

true. I've maintained the functionality of making sure the values sent back 
out of GD *look* like GD output values in order to make sure that there can 
be no underlying problem (for example with colorAllocate which wants an 
integer back).

> 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.
>

I'm not so sure it's overkill. You will have a tough time with the cut & paste 
functionality for GD. and with the background image functionality. If you 
don't fully support the GD API, then you will cause users issues with their 
inability to do a GD action on their graph that they expect to be able to do.

Think of GD as an API standard. If you don't support the entire standard, then 
you have to do a serious song and dance to justify and explain the holes. Of 
course, SVG::GD is as incomplete as GD::SVG, but it is important to keep in 
mind that users will want to implement standard GD calls.

Granted, you are attempting to implement only a specific set of drawing 
routines, and hence you do not necessarily need to do complicated things like 
support bitmap-supplied brushes or draw on top of an existing image.

> 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.  

You're right that it's not the *fastest* way to do things. There is a real 
performance hit from maintaining the GD raster in memory

>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.

The SVG image size is high for complex images, but since the SVG standard 
includes compression with gzip, there is a significant reduction in size. I 
rarely see png or gif images of any significance (say larger than 300 x 400) 
that are smaller than gzipped SVG output.

>
> 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.
>

I think this is a good and pragmatic approach, and the approach I am currently 
limited to in release 0.07 of SVG::GD. But it prevents your users from 
enabling some important functionality such as fills from the colour at a 
given point.

> 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.
>

That's also a good idea. Until someone comes up with SVG::Canvas, then 
maintaining a GD-based canvas seems like a fairly good, pragmatic approach.

Ronan

> 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

-- 
Ronan Oger
http://www.roasp.com
Serverside SVG Portal