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

[Nicolas Limare]

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

The second question is still open. With your example,
  <img src="/scripts/convert?image.svg&image.png" width="440" height="440" />
the convert script doesn't know the output image needs to be 440x440
pixels. Converting the svg to a png at the good resolution is
important to avoid resizing artifacts. So the script must acccept 3
arguments, input, output and size.
Then, what happens when the script is called twice with 2 different
sizes?
  <img src="/scripts/convert?image.svg&image.png&size=440x440" />
  <img src="/scripts/convert?image.svg&image.png&size=440x440" />
At the first call, image.png is generated with 440x440 pixels. At the
second call, image.png already exists, so either it is kept and used
for the 220x220 image with resizing, or it is replaced by a 220x220
image, and resized in browser for the 440x440 call. Not good. So we
need different file names for different sizes. Then will we accept any
size, up to 4.10^18 maximum size of a PNG image? I don't think so, so
we need a max size limit. And the file names must be sanitized to
avoid directory traversal exploits. And so on. To be done properly, a
svg->png converter might get a little complex. It's not a big software
project, but it is definitely more than a couple of hours one
afternoon.

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

I still want to improve some aspects of the demo system before
considering more features: a clean, simple build system; a better and
more scalable archive system; a better image library derived from
PIL.Image; a solution to run the binary proigrams in an isolated
environment. So I don't think I will work on new features, I prefer to
build stable foundations. But contributions in the form of new
features are welcome, if maintained.

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

We already have the same situations with demos producing TIFF
images. Every time a new TIFF output is produced or modified, a PNG
version is produced, because the author of the demo added a line in
the demo code for this conversion
  im("foo.tiff").save("foo.png")
It's really basic, but it works. I thought the same kind of thing
would be ok for svg.

-- 
Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
IPOL - image processing on line                          http://www.ipol.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://tools.ipol.im/mailman/archive/discuss/attachments/20110909/02bb5c84/attachment.pgp>