Bug 3225

Summary: Make thumbnails adhere as closely as possible to the fdo spec
Product: openclipart.org Reporter: Jonadab the Unsightly One <jonadab>
Component: toolsAssignee: default user for a product <clipart>
Severity: enhancement    
Priority: high    
Version: unspecified   
Hardware: All   
OS: All   
URL: http://jens.triq.net/thumbnail-spec/index.html
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 3347    
Attachments: Script that uses inkscape and imagemagick to generate a thumbnail that is 128 pixels in the larger direction

Description Jonadab the Unsightly One 2005-05-06 16:57:50 UTC
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.
Comment 1 Nathan Eady 2005-05-20 10:29:13 UTC
-> me, at least for the moment.
Comment 2 Andrew Archibald 2005-05-20 11:02:07 UTC
Created attachment 2725 [details]
Script that uses inkscape and imagemagick to generate a thumbnail that is 128 pixels in the larger direction
Comment 3 Nathan Eady 2005-05-20 11:08:01 UTC
Also note the Wiki page about this issue:

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.]
Comment 4 Andrew Archibald 2005-05-20 22:12:52 UTC
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). 
Comment 5 Jonadab the Unsightly One 2005-05-30 06:43:18 UTC
Thumbnails need to be 128 pixels *square* (128x128), not just 128 pixels in
the larger direction.
Comment 6 Jonadab the Unsightly One 2005-08-28 18:29:54 UTC
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.
Comment 7 Jonadab the Unsightly One 2005-08-28 18:43:07 UTC
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?
Comment 8 Patricia FIDI 2006-07-13 04:56:19 UTC
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)
Comment 9 Nicu Buculei 2006-07-13 05:17:52 UTC
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.
Comment 10 Carsten Schmitz 2006-07-13 10:24:04 UTC
(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).
Comment 11 Bryce Harrington 2006-07-13 15:16:39 UTC
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.

Comment 12 Patricia FIDI 2006-07-14 16:43:51 UTC
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) ;-)

Comment 13 Roan 2006-07-14 23:16:00 UTC
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.

Comment 14 Thomas Zastrow 2006-07-15 02:25:37 UTC
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?
Comment 15 Patricia FIDI 2006-07-15 05:35:29 UTC
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

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

Comment 16 Nicu Buculei 2006-07-17 00:02:26 UTC
(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)
Comment 17 Jon Phillips 2007-02-05 15:46:13 UTC
Yes, I agre....
Comment 18 Tollef Fog Heen 2010-08-18 03:23:49 UTC
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.