Bug 3225

-> 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.