[Gridflow-dev] [PD] pd2png : screenshots of patchs

[s p]

> Do those patents matter ?

It depends for who! That's an ideological debate ... for me they do matter,
but I can understand that some don't really care, ... even though
open-source advocates would argue that it's in their own interest to care :)


> PDF is just a binary version of PS. It's essentially the same format.

Ok, I didn't know. But that's not really the point. The point is that
nobody uses PDF to generate images programmaticaly. Maybe you know PS well,
and "if *all you have is a hammer*, everything looks like a nail" (just a
joke), but basically (to my knowledge), SVG is what programmers use to
generate vector images. Never heard of a single project that would use
another format, unless very special requirements.
But to me the killer argument is that SVG is supported natively in all
major browsers. And obviously web technologies are the future. They are
already conquering mobile apps. I c


> Anyway, what extra data will you put there, and especially, who will read
it, how ?

I think you didn't really understand what I meant. SVG is XML, and XML
represents a datastructure. So in its very structure, it embeds the
information that is contained in a patch.
A Pd patch is mostly a graph, and this is exactly what an XML document is.
Of course, you need to add a few more infos here and there, for example a
class, so that you know if this <rect> is an object or an inlet and so on
...
To give you an idea of what I am talking about, this is a simple patch,
translated to SVG with pd-fileutils : http://pastebin.com/bVW2NUx2 ; I
don't even need to tell you what the patch is, as this is human-readable
which is also quite nice.


> Then you open a SVG file in a SVG editor, and then save it, and all that
extra data is gone

I just tried with inkscape, opened a file and saved it again in inkscape's
own SVG format, and that information is saved intact.


> When the point is to have pixel-perfect reproduction, I precisely don't
want a vectorisation to happen.

But is there actually any case when you care about pixel-perfect
reproduction?
On the other hand, when you have vector graphics, especially SVG that is
extremely easy to manipulate and that has a huuuuge amount of libraries to
handle manipulations, you can actually do much more interesting stuff, like
using automatic-layout algorithms. This is what I did in this little
example : http://sebpiq.github.io/pd-fileutils/randomDrone.html I am
generating patch programatically, therefore, I have no layout information.
So I used a layout algorithm provided with d3.js (http://d3js.org/ , which
is by the way a beautiful example of a very mature, reliable library
allowing to handle SVG very easily).



2013/5/20 Mathieu Bouchard <matju at artengine.ca>

> Le 2013-05-20 à 09:20:00, s p a écrit :
>
>
>  Even though PDF is an open spec, Adobe still has some patents on it.
>>
>
> Doesn't seem to stop anybody in the free software world, even though GPL
> is incompatible with patents. Do those patents matter ?
>
>
>
>  PS on the other hand is a very specific format that's almost not used
>> anywhere else than for printers.
>>
>
> PDF is just a binary version of PS. It's essentially the same format.
>
>
>
>  - it is not only an image format, but also a data container. In our case
>> it holds information about what's in your patch.
>>
>
> Then you open a SVG file in a SVG editor, and then save it, and all that
> extra data is gone, because the editor didn't think about remembering it.
>
> Anyway, what extra data will you put there, and especially, who will read
> it, how ?
>
>
>
>  > There are plenty of image conversion tools from many formats to many
>> >others
>>
>> Good luck in trying a conversion tool raster -> vector that gives you
>> meaningful results.
>>
>
> When the point is to have pixel-perfect reproduction, I precisely don't
> want a vectorisation to happen. And I've usually wanted a pixel-perfect
> reproduction, though vectorial representations are also useful.
>
>
>
>  In that sense SVG is more central than a raster format.
>>
>
> Yup...
>
>
>  ______________________________**______________________________**
> __________
> | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.artengine.ca/pipermail/gridflow-dev/attachments/20130520/3951ca7c/attachment-0001.html>