[Bioperl-l] identifying objects in Bio::Graphics SVG

[Todd Harris]

Jonathon pretty much beat me to the answer.  GD::SVG is really just intended
as proxy for GD.pm to get SVG output from GD scripts.

It doesn't take advantage of much of the richness of SVG since these
elements reside outside the scope of GD.  That said, I have experimented
with minor things like adding descriptive IDs to SVG objects.

I'd be interested to see if boxes() will work with GD::SVG rendered panels.
I suspect it will choke - please let me know.  It shouldn't be too hard to
add this support which might allow greater SVG flexibility from
Bio::Graphics for the short term.

For the longer term, I'd rather see generic Bio::Graphics objects that
contain no format-specific graphic generation.  These would in turn use
Bio::Graphics::SVG, Bio::Graphics::Postscript, to draw/calculate the actual
primitives as necessary.  Given the duct-tape approach of GD::SVG,
overloading it to handle the additional options of SVG could get messy -
fast.  Duck and cover.

Todd

> On 8/6/04 1:20 PM, Crabtree, Jonathan wrote:

> 
> Hi Steve-
> 
> I looked into this briefly and I'm pretty sure that the answer is "no".
> The way that the Bio::Graphics module generates SVG output is by using
> GD::SVG, which is more or less a drop-in replacement for GD.  Since the
> GD API doesn't require (or permit, AFAIK) the association of logical
> identifiers with graphics primitives (e.g., these four lines are part of
> exon #1234), this information isn't included in the GD API calls and
> therefore isn't available to GD::SVG.  So even if GD::SVG wanted to
> group the various elements within an SVG <g>roup, it doesn't have any
> way of gleaning the necessary information without going beyond the GD
> API.
> 
> Now of course this isn't to say that it wouldn't be possible to
> implement this type of functionality, but it would require making
> Bio::Graphics somewhat more SVG-aware than it is now, and would probably
> entail delving into the workings of GD::SVG a little bit.  I can also
> imagine taking a somewhat heavyweight approach that would be relatively
> inefficient but might be easier to implement.  One could conceivably
> make a fresh GD::SVG object for each glyph to be rendered, and then add
> some code to Bio::Graphics to strip out the essential SVG rendered by
> each glyph, wrap it in a <g> element, and place it into a dummy
> top-level GD::SVG object that serves only to collect the text of the SVG
> document.  I don't know...at some point it's going to be easier to just
> go ahead and add direct SVG support into Bio::Graphics.
> 
> Jonathan
> 
> p.s. Re-reading your original message, it might be possible to do
> something using the bounding box of the feature of interest (which can
> be obtained from the Bio::Graphics panel) to search through the SVG text
> for the relevant section.  It would be messy, though, and rather
> indirect.
> 
>> -----Original Message-----
>> From: bioperl-l-bounces at portal.open-bio.org
>> [mailto:bioperl-l-bounces at portal.open-bio.org] On Behalf Of
>> Roels, Steven
>> Sent: Friday, August 06, 2004 1:49 PM
>> To: bioperl-l at bioperl.org
>> Subject: [Bioperl-l] identifying objects in Bio::Graphics SVG
>> 
>> 
>> 
>> Hello,
>> 
>> I'd like to take the nice SVG output I can generate with the
>> Bio::Graphics modules, and add javascript to (for example)
>> alter/hide elements based on a slider or other user-controlled input.
>> 
>> Is there a way to map various panel items to the resulting
>> svg components?
>> 
>> e.g transcript3, exon4 == <rect id="3633-9-510">
>> 
>> Given that the "<g>" grouping element doesn't seem to be used
>> (which would facilitate this for non-simple elements), I'm
>> guessing not, but thought I would ask.
>> 
>> Thanks,
>> 
>> -Steve
>> 
>> *****************************************************************
>> Steve Roels, Ph.D.
>> Senior Scientist I
>> Computational Biology
>> Millennium Pharmaceuticals, Inc.   Phone: 617.761.6820
>> 640 Memorial Drive                 FAX:   617.577.3555
>> Cambridge, MA 02139-4815           Email: steven.roels at mpi.com
>> *****************************************************************
>> 
>> 
>> 
>> 
>> This e-mail, including any attachments, is a confidential
>> business communication, and may contain information that is
>> confidential, proprietary and/or privileged.  This e-mail is
>> intended only for the individual(s) to whom it is addressed,
>> and may not be saved, copied, printed, disclosed or used by
>> anyone else.  If you are not the(an) intended recipient,
>> please immediately delete this e-mail from your computer
>> system and notify the sender.  Thank you.
>> 
>> 
>> _______________________________________________
>> 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
>