[PD] pd -> svg

s p sebpiq at gmail.com
Tue May 14 12:35:14 CEST 2013


Anyways ... those are all great ideas for sure but they require work. If
you want to try your hand at that, I'll be very very happy to get some help
on those projects (pd-fileutils, WebPd)    :)

For those bugs with the SVG rendering, I should be able to get to this next
week, and I'll keep you updated once this is fixed, so you can play with it.


2013/5/14 András Murányi <muranyia at gmail.com>

>
> On Tue, May 14, 2013 at 12:43 AM, Jonathan Wilkes <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>wrote:
>>
>>> >From: s p <sebpiq at gmail.com>
>>> >To: Jonathan Wilkes <jancsika at yahoo.com>
>>> >Cc: PD List <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
>
>
>
>>
>>
>>  But even better, CSS attributes could be used, which can hold URL
>> values without base64-encoding, and they are also more variable (can be
>> defined elsewhere than in the HTML source, can be overwritten/cascaded
>> without Javascript).
>>  This way, the pd-source defined right in the HTML source would look
>> like: <img src="mypatch.svg" style="thisproperty: 4px; thatproperty: 30%;
>> -pd-source: url(file://C:\Users\Joe\Desktop\mypatch.pd)" />
>>  Note that the etiquette for introducing non-standard CSS attributes is
>> to start them with the hyphen. (E.g.: -moz-box-shadow) (Similar to custom
>> mime-types beginning with "x-something-")
>>  This method would open up an unlimited number of possibilities, just to
>> note a few:
>>  - the pd source could be at any URI that the client can parse: a local
>> filesystem, the web, ftp, or even git
>>  - it would be easy to parametrize a patch using further attributes
>> (even addressing recieves!) like -pd-param-myparameter (and note that CSS
>> has official support for units like colors, angles, times, and frequencies)
>>  - there are robust classes available for the management of CSS
>> attributes, first of all with Javascript of course
>>  - seamless integration with a JSON based pd source format would be
>> trivial (http://lists.puredata.info/pipermail/pd-dev/2012-06/018436.html)
>>
>> http://www.w3.org/TR/2008/REC-CSS2-20080411/syndata.html
>>
>> András
>>
>>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130514/c3ac4e71/attachment.htm>


More information about the Pd-list mailing list