[IPOL discuss] Vector graphics on IPOL: which format to use?

[Miguel Colom]

> Do you mean, we would not have the PNG file stored on the server, but
> - if the http server receives a request for a PNG file /path/to/foo.png
> - and if there is no such PNG file /path/to/foo.png
> - and there is a SVG file /path/to/foo.svg
> - then some program will render the svg file in a PNG bitmap and send
>   it as the answer to the request for /path/to/foo.png

Yes, this is what I mean.
Although instead of detecting a non-existing file, we could call a server
script that does the conversion and redirects to the resource.

For example, something like this:

<object type="image/svg+xml" data="image.svg" width="440" height="440">
  <img src="/scripts/convert?image.svg&image.png" width="440" height="440" />
</object>

> This leaves some questions open:
> * Which program would you use to do the SVG->PNG rendering? http
>   servers don't do it, nor CherryPy. PIL doesn't read SVG. Maybe
>   inkscape, or imagemagick? Then these programs must be available on
>   the server whenever it is serving svg content.

We've got many alternatives. Imagemagick is a good one, for me.
The conversion script should be responsible of calling the adequate
programs to do the conversion and it should have a well-defined interface.
For example, first parameter: the image being converted, second parameter:
the output. And perhaps restrict it only to PNG files, for the sake of
simplicity.

> Moreover, I don't understand why you want to make the server more
> intelligent and more complex. My opinion is that, even if it's not
> exciting, building the content and having everything available as plain
> boring static files in the server is simple, stable, and
> future-proof. Who will write and maintain an on-the-fly svg-to-png
> conversion service?

If we want it to have more features, the system will be more complex,
unfortunately. We can't avoid it, but we can do out best to make it
scalable.

The problem with static files is, in my opinion, that we should ensure
that when the SVG file is changed, the PNG is changed at the same time.
Doing this automatically, is the best solutiion.

Moreover, the demos can generate SVG figures dinamically in every
execution, so I think the SVG-->PNG automatic fallback is the best
solution.