Dean Arnold <darnold@xxxxxxxxxxxxxx> writes:
> Jack D. wrote:
> > Holy moly - Now I see why you are confused! Effectively - that is
> > something
> > like what I'm talking about.
> > I see that having an SVG->Canvas converter and a Canvas->SVG would
> > definitely be an asset. One could draw a picture (using another graphics
> > tool) - save it in SVG format and then have it plotted on a Tk::Canvas. That
> > being said - my driving force behind this, was not to *store* a canvas - but
> > rather to *plot* canvas items by reading the data from outside the program!
> > But now I see that they are one in the same thing. The analogy is to store a
> > file and read a file, the former must be done before the latter - duh! Ala
> > said it succinctly - a "persistent canvas". I see that Slaven has such a
> > utility in his CanvasUtil.pm module using storable.
> >
>
> 1) There are already some SVG generators available on CPAN
> (GD::SVG, plus a couple others). That part should be
> fairly simple to wrap in a Tk->SVG converter.
>
> 2) The other way round (SVG->Canvas) may be a bit more
> challenging, tho theoretically some sort of XSLT might
> produce Perl/Tk code from an SVG input ?
>
Not only theoretically, see the both attachments. The stylesheet is
the result of a little bit playing around with xslt and svg, nothing
really serious. You can try it out with a xslt processor like xsltproc:
xsltproc svg.xsl test.svg | perl -
But I am not sure that Jack needs some kind of XML solution. Why bot
using just Perl?
| item of type PIREP is a triangle
| item of type UNOFFICIAL OB is a circle
| item of type SWED is a square
would map into a hash (item type => canvas type)
| if header contains UACN or UBUS then
| set item type to PIREP
| otherwise if header contains SXCN then
| set item type to UNOFFICIAL OB
| otherwise if header contains SWED then
| set item type to SWED
| End
would also map into a hash (header => item type) or maybe a list of
regular expressions mapped to item types. These hashes could be moved
out of the application into a .pl or .pm file which means that parsing
would be done with a simple "require" or "do" call --- no external XML
parsers needed. Processing data would be quite natural --- no complex
DOM operations or non-intuitive handling with XML::Parser necessary.
Regards,
Slaven
svg.xsl
Description: Binary data
test.svg
Description: Binary data
--
Slaven Rezic - slaven <at> rezic <dot> de
Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net
| 
