[PD] pd -> svg

Jonathan Wilkes jancsika at yahoo.com
Tue May 14 19:00:37 CEST 2013

On 05/14/2013 06:22 AM, András Murányi wrote:
> On Tue, May 14, 2013 at 12:43 AM, Jonathan Wilkes <jancsika at yahoo.com 
> <mailto:jancsika at yahoo.com>> wrote:
>     On 05/13/2013 02:56 PM, András Murányi wrote:
>>     On Sun, May 12, 2013 at 1:02 AM, Jonathan Wilkes
>>     <jancsika at yahoo.com <mailto:jancsika at yahoo.com>> wrote:
>>         >From: s p <sebpiq at gmail.com <mailto:sebpiq at gmail.com>>
>>         >To: Jonathan Wilkes <jancsika at yahoo.com
>>         <mailto:jancsika at yahoo.com>>
>>         >Cc: PD List <pd-list at iem.at <mailto:pd-list at iem.at>>
>>         >Sent: Saturday, May 11, 2013 4:37 PM
>>         >Subject: Re: [PD] pd -> svg
>>         >
>>         >Thanks Jonathan,
>>         >
>>         >I don't really have the time to take care about this those
>>         days, but I'll fix it as soon as possible, and post here when
>>         that'll be done.
>>         >
>>         >Cheers,
>>         >
>>         >Sébastien
>>         Here's an idea...
>>         Suppose I build a Pd gui-plugin that exports a Pd file to
>>         svg.  It takes the toplevel patch and makes the drawing
>>         instructions like my example in the OP.  But it also draws a
>>         little navigation bar at the bottom with 1) a little image
>>         with id="source patchname", 2) a play button with id =
>>         "webpd-play patchname", 3) a stop button with id =
>>         "webpd-stop patchname"
>>         The image with id="source patchname" is the base64-encoded
>>         source of the patch.  This would be neat because:
>>         a) Anyone could export to svg and get a file that can be
>>         displayed in any modern browser (with searchable/selectable
>>         text in most of them).
>>         b) Since the drawing instructions Pd uses are so simple the
>>         svg will probably display on mobile devices (even older ones).
>>         c) Since the source is embedded in the file, webpd js could
>>         just listen for clicks to any webpd-play buttons in the page,
>>         and when it catches one it looks for an svg image with id
>>         "source" plus the same patchname as the webpd-play button. 
>>         It then decodes the image, loads it and plays it until it
>>         receives a "webpd-stop" button click.
>>         This method has the benefit of degrading gracefully; that is,
>>         if someone using NoScript wants to read a forum with pd patch
>>         svg images in it, they will still be able to view the image. 
>>         Moreover, a forum admin or blog owner can post the svgs
>>         simply to show pictures of patches; then later when the audio
>>         api becomes more common than just firefox nightly they can
>>         add the webpd code once and all their images will now feature
>>         audio.
>>         -Jonathan
>>     This sounds extremely appealing to me.
>>     About the HTML side, be careful with using the ID field because
>>     it can be used only once and then other uses become impossible.
>>     Also, it has to be unique which would effectively prevent the
>>     same patch from being embedded more than once.
>>     You might want to consider the CLASS field instead which can hold
>>     an unlimited number (theoretically; the practical limit is around
>>     2000) of classes, and classes are already used deliberately to
>>     signify different attributes of HTML elements.
>>     I'd also recommend prepending the string with something constant
>>     that will allow the automatic discovery of such strings among
>>     other, non-pd-parseable strings (versus having plain
>>     base64-encoded strings, which are not detectable by themselves,
>>     or, at least, must be decoded before recognized). For separating
>>     the prepended part from the base64 part, CSS allows for any ISO
>>     10646 character higher than U+00A1 to be used, or even lower
>>     characters when escaped with backslash.  (I don't recommend an
>>     escaped character because the backslash might "disappear" while
>>     the HTML get processed by various scripts here and there.)
>>     For example: <img src="mypatch.svg" class="thisclass thatclass
>>     pd-source_ABC123BASE64STRING" /> would be a nice extendable format.
>     I just noticed that svg isn't allowed as a "media type" in
>     Wordpress by default.  I'd imagine the same is probably true for
>     forums, too, making it less flexible than, say, exporting a patch
>     to png or something.  (And png has a "comment" section of
>     essentially arbitrary length that I could abuse to store the
>     pd-file along with the png.)
>     Still, the fact that you can zoom in losslessly on a svg is very
>     appealing.  If I grouped the drawing instructions for each object
>     with <g> and put the name + args somewhere in there, it'd be
>     pretty easy to convert the svg to pd file (at least for simple
>     patches... subpatches might pose a problem).  I like the idea of
>     the source being available within the diagram itself, it'd make it
>     much less work to do stuff like a presentation through a browser,
>     and later adding audio to it.  (And even later, taking those
>     groups and manipulating them with the mouse.)
>     Thanks for the info on CSS, I'll look into it further. I just
>     started researching all this stuff, and everything has many ways
>     to solve the same problem (i.e., html5 canvas, svg, css, not to
>     mention all the javascript libraries to manipulate all of those).
>     -Jonathan
> The Wordpress problem is easy to come around by a plugin 
> (http://wordpress.org/extend/plugins/scalable-vector-graphics-svg/) or 
> an addition to the functions.php file in the template 
> (http://wordpress.org/support/topic/svg-upload-not-allowed?replies=9).
> I imagine the play button and co would be drawn by a wrapper 
> (Javascript) too. That's how I actually imagine backwards 
> compatibility: where not supported, only the image of the patch is 
> displayed.
> I'd love to discuss this further with you, and willing to put work 
> into it. I'm pretty confident when it comes to browsers and CMSs ;)
> András

Sounds great.  I'll look into this some more.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130514/ff753fd0/attachment.htm>

More information about the Pd-list mailing list