On 05/14/2013 06:22 AM, András Murányi wrote:
On Tue, May 14, 2013 at 12:43 AM, Jonathan Wilkes <[email protected]
<mailto:[email protected]>> wrote:
On 05/13/2013 02:56 PM, András Murányi wrote:
On Sun, May 12, 2013 at 1:02 AM, Jonathan Wilkes
<[email protected] <mailto:[email protected]>> wrote:
>From: s p <[email protected] <mailto:[email protected]>>
>To: Jonathan Wilkes <[email protected]
<mailto:[email protected]>>
>Cc: PD List <[email protected] <mailto:[email protected]>>
>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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
