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