[Clipart] clipart Digest, Vol 42, Issue 27

Greg Bulmash oneminuteinspirations at gmail.com
Mon Sep 24 09:27:33 PDT 2007


On 9/24/07, Nicu Buculei <nicu_gfx at nicubunu.ro> wrote:
> The main difference: those sites work with images in raster formats. is
> trivial to work with built-in php functions (gd library) with raster
> images, produce thumbnails or so, is not that easy to convert from SVG
> to raster, both gd and imagemagick support only subsets of the SVG standard.

First, let me outline my new image import process...

SVG's go through a batch process in Illustrator that removes any page
boundaries (setting the "document" size to the image size) and export
a copy to SWF as that's needed for the FunDraw Flash application to
make best use of the graphics.

SVGs go through a second batch process in Inkscape, converting
everything to EPS (better and more reliable for use in the PerlMagick
script I use to turn the XML produced by the FunDraw Flash application
into a raster) and then actually doing a text append to ensure
ImageMagick interprets them as postscript level 3 (for better
transparent background support).  Inkscape's EPS export is a bit iffy,
but it creates EPS files about 1/3 or smaller than Illustrator's.

Third batch uses Inkscape to create the high-resolution PNGs for
"super resolution" downloads.

Fourth batch uses ImageMagick to create mid-resolution JPEGs from the EPS files.

All the files are then put in a big directory.  A PHP script then
iterates through the .SVG filenames and shows me a web form containing
the SVG, SWF, and JPEG.  All of them have to look exactly the same so
I'll have consistency in the clipart library, Flash drawing
application, and JPEGs produced from the drawing application.

If they don't look the same, they either get discarded if it's thought
they can't be easily fixed manually, or they get put aside for manual
adjustment.

Those that pass the visual check are assigned a name, categories,
keywords and a description, then added to the clip art library
database.

After a pass through them, thumbnails are created from the
mid-resolution JPEGs, all the images are uploaded into the proper
folders on the live site, and the database on the live machine is
synched with the newly-updated one from the test machine.  Then
additional batch processes are run to incorporate the new clipart into
the static pages of the galleries.

So, while it's doable with a one-man operation, I actually have to do
a lot more with each SVG than you guys do because I'm using it in so
many different ways.

That said...

Second, Inkscape has some halfway decent commandline utilities for
rendering SVGs into bitmaps.  Using shell_exec() in PHP can let you
script that.  You just need to make sure you sanitize the filenames so
there's no possibility of an injection exploit.  On upload, you could
create multiple sizes of previews in a few lines of code.

Step 1: Convert SVG into PNG with commandline Inkscape through shell_exec();
Step 2: Use GD to get dimensions of PNG
Step 3: Do calculations so thumbnails and other sizes fit within
predetermined bounding boxes.
Step 4: ImageMagick does resize/copy giving each image a prefix or
suffix unique to the size type.

Then, let's say your uploaded file is nicu_ogre_club.SVG, you might
end up with...

nicu_ogre_club.SVG
nicu_ogre_club.PNG
nicu_ogre_club.500.JPG (fits in a 500x500 bounding box)
nicu_ogre_club.thumb.JPG (thumbnail fits in a 125x125 bounding box)

> The core of ccHost is mp3 sharing, so it have the base covered for mp3s
> features (so it does not need thumbnails for mp3s), adapting it for SVG
> was our gimmick in the lack of another alternative.

Perhaps it's better to start from scratch and do something that's
optimized for SVG/bitmap sharing instead of trying to crowbar that
function into CCHost?

- Greg



More information about the clipart mailing list