In particular, the fdo spec says 128x128 pixels for normal-sized thumbnails. This means we need to figure out how to make them all square, perhaps by padding them with a square transparent background. Currently, we are using Inkscape from the command line to generate thumbnails, something along these lines: inkscape -f "$filename.svg" -e "$filename.png" -w 80 What that does is makes the width a specific value (80, but we could make it 128 easily enough), and lets the height be determined automatically based on the aspect ratio. So the results are not necessarily square. Thus bug really belongs in the tools component, once that exists.
-> me, at least for the moment.
Created attachment 2725 [details] Script that uses inkscape and imagemagick to generate a thumbnail that is 128 pixels in the larger direction
Also note the Wiki page about this issue: http://openclipart.org/cgi-bin/wiki.pl?Thumbnail_Support Nicu suspects we can solve this with Image::Magick, and I suspect he is right. There may even be something in the cookbook for this one. [Update: while I was posting that, Andrew attached the above attachment, which I need to look at now.]
I just checked a fix into CVS; thumbnails are now 128 pixels in the larger dimension. (As for storing thumbnails in the fd.o spec location, I don't think we can do that; we could also generate 256-pixel thumbnails).
Thumbnails need to be 128 pixels *square* (128x128), not just 128 pixels in the larger direction.
Okay, finally got back to this. It was easy, once I looked into it, so I've checked into CVS a version of generate-thumbnails.pl that does this. It will appear in the tools for the 0.18 release. We still need to make the release process (which currently uses svg_validate) get the thumbnails right, either by having it use generate-thumbnails.pl or by making svg_validate generate the thumbnails with the correct dimensions. Once we've done that, we run generate-thumbnails.pl once over the whole collection and Bob is our uncle.
What are other people's thoughts on 256-pixel thumbnails? I can't stop thinking about how much they would increase the package sizes, but what do others think?
Hi all, I've sent an SVG clipart with 80px of large like PNG used in OCAL (name is headphone in incoming files of http://www.openclipart.org). At the very beginning of OCAL, browsers couldn't read and show SVG files but now it's OK for all browsers. We may ask people to upload only SVG files with 80px of large. -> less work for us with thumbnails, PNG files... -> no implementation of library or tool during upload... (my answer is in bug 3225 and 3347, if everybody is OK, we may closed this old discussion from 2005) Patricia
When we talked about merging OCAL back into Inkscape, the idea of dropping monthly releases appeared and was not opposed by anybody. Without releasing packages, the only use for thumbnails is on the website (ccHost), where the size is important only for the page layout and loading time. I think we should have a decision about this: we will release packages in the future? If yes, the packages would still contain thumbnails? My take would be "NO" for both cases, but it have to be decided in a democratic way.
(In reply to comment #9) > I think we should have a decision about this: we will release packages in the > future? If yes, the packages would still contain thumbnails? > My take would be "NO" for both cases, but it have to be decided in a democratic way. I agree to both points but there should be still the possibility to download all clipart in one package (maybe from an monthly auto-generated package).
I'd vote in favor of keeping a monthly (or periodic) tarball of images. I think if we stop doing this, users and distros will put in a lot of requests for it anyway. I think most people will dislike having to individually download each SVG from the website. Bryce
Hi all, I'm in favor too with Carsten and Bryce for : * a periodic zip and tarball images archive (as soon as 500 new incoming svg files ?) I'm in favor too with Nicu for : * only SVG files in archive and on website --> no more PNG pictures and on the website, near the download archive link, maybe a link for downloading Adobe SVG viewer (2,1MB) for IE users or Firefox for windows (8,1MB) ;-) Patricia
I vote to keep periodic official releases (zip and tar.gz/bz2) which contain only svg files--This will allow for maximum compression. I think it is too early to give up thumbnails on the website. While browser support has come a long way for svg in the last year or two, it still has a ways to go before svg graphics can be a major design component of a web page. Perhaps a compromise would be a system that auto generates png thumbnails as needed. The thumbnails would then be kept on the server for a period of time (say one week after last access). After a week of not being viewed, they would be deleted. Zope implements a system like this for their "photo album" product. It seems to be a nice balance of hard drive resources versus processing resources. --Roan
Sometimes ago I wrote a little script which produces a PDF-file of all the images in OpenClipart. Perhaps it could be useful to provide such a catalogue as optional download instead of the PNG-files?
Hi Thomas, The script for PDF catalog is a very good idea ! - In big cities in Africa, they often have connexion by satellit (download) and a little modem of 33,6K (upload). So if they have the link of the PDF catalog, they will be able to download very fast. - for teachers, it's better to print a PDF catalog for the classroom for their project The target of OCAL is to spread SVG but I saw people using only PNG files of SVG flags I've made... So the catalog is here again a good idea. ----------------------- Hi Roan, Sometimes, windows users don't know either what is a PNG file... I often have to convert a PNG to JPG for them... but now people may have IE and firefox on windows... Patricia
(In reply to comment #13) > > I think it is too early to give up thumbnails on the website. This is not abut the thumbnails on the website, where we still need those, but about the thumbnails in packaged releases. A couple of arguments for not having thumbnails in releases: - is against our intention to spread the usage of SVG - is not really useful for our uses to have 128x128 PNG images, they would need larger rezolutions (but this would increase the size of the package for download, would require additional maintenance)
Yes, I agre....
Closing all openclipart bugs as openclipart is now on launchpad, as per request from Jon Philips.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.