[Clipart] [Cctools-cchost] function for generating png thumbnails from svg files

[Roan Horning]

Victor Stone wrote:
 > that's great and we definitely want to include in cchost, however with
 > a big caveat because many shared hosting sites disable exec() from php
 > script so while technically it's not a generic php solution, enough
 > folks are hungry for it as you've spec'd it.
 >
I'm trying to keep the code as generic and modular as possible. 
Currently it does heavily rely on the exec() command. I'm using it to 
call inkscape for two things. First is to retrieve the height and width. 
The second is to generate the desired size png.

The getid3 svg module will return the height and width of an svg So I 
can easily replace those inkscape calls.

I see there are two PHP interfaces available for using ImageMagic:
MagickWand for PHP and IMagick.

I could use ImageMagic with one of those interfaces to drop the exec() 
function. I initially chose Inkscape because I am familiar with it, and 
it is targeted at svg, so I wasn't worried about it's ability to create 
a nice thumbnail from whatever svg file it was given.

Does anyone have any opinions on ImageMagic's handling of svg files? Are 
there other conversion tools out there with php hooks?

 > There are two things to consider here that I can think of
 >
 > 1) caching YES.
 >
 > You want to watch for cchost events
 > UPLOAD_DONE (to create the thing)
 > UPLOAD_DELETE (to clear the cache)
 > FILE_DONE (to watch for file adds/deletes/replaces)
 >
Not yet being that familiar with the cchost code, I was thinking of just 
adding a check for the existence of a thumbnail in 
pages/places/templates that return html thumbnail code.  If it doesn't 
exist, then it is created. Of course this could slow to a crawl a page 
which calls a number of thumbnails that don't exist.

 > remember that an upload record can have multiple images, each with
 > it's own thumbnail. Now you may make an executive decision to only
 > thumbnail the first one and that's totally cool. This is the decision
 > I came to when doing the flash-mp3 player and playlists: that only the
 > 'top' file in the upload record is retrieved when the user requests
 > 'play'
 >
We could have 128px be the default thumbnail size which gets saved in 
the same directory as the svg file, but give people the option of 
viewing other sizes of thumbnails. These other sizes would go in a 
temporary cache.

 > 2) keep the actual thumbnail creation code isolated from everything
 > else. This allows for Inkspace dependency to be easily isolated and
 > replaced, but also allows for us to use that smarts in other areas of
 > the code (like when a user uploads an avatar that's too big, instead
 > of rejecting it we should shrink it to the right size)

So we want a more generic thumbnailer function that handles multiple 
graphic formats? This leans me toward using an ImageMagic interface.

Or should I break it up into smaller pieces. One function to return the 
longer side of a graphic. The thumbnailer function to create it.

Currently it is called by: svg2thumbnail(<path to svg file>,<size of 
thumbnail as a single number>)

It creates a png file with the name of the svg suffixed with "-tn<size 
of thumbnail>.png".  So svg2thumbnail("/var/www/drawing.svg","128") will 
give you a file: /var/www/drawing-tn128.png

What options would be desirable for this function? It would be easy to 
make a passed thumbnail size of "0" default to the full size of the svg.
So and svg with a width of 270px and height of 290px called as 
svg2thumbnail("drawing1.svg", "0") would give you drawing1.png with a 
size 270px X 290px.

It could also accept an option that lets one set whether the file name 
gets a prefix or suffix which includes the thumbnail size (ie 
tn128-drawing.png or drawing-tn128.png).

thanks for your input.

Roan