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

[Greg Bulmash]

Last I checked, IMagick ran out of steam in 2005, and you'll have to use 
a legacy version of ImageMagick to get it running.  OTOH, though the 
original developer of MagickWand dropped off the face of the earth, the 
ImageMagick development team took his fumble and ran it in. 
*Definitely* recommend Magick Wand over Imagick.


Roan Horning wrote:
> 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
> _______________________________________________
> clipart mailing list
> clipart at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/clipart
>