[Clipart] Thumbnails in clipart packages

[Bryce Harrington]

On Fri, 16 Jul 2004, Jonadab the Unsightly One wrote:

>   
> Okay, I'm thinking some more about specifications for a clipart
> package format, and here's what I'm currently thinking.  (Anyone with
> better ideas should speak up soon; within a month or so I want to
> implement a module for working with these packages.)
> 
> 1.  Use ZIP format.
> 2.  Inside the zipfile, everything should be inside a single
>     directory called clipart

Perhaps it may be wise to follow the tar convention and have the
internal directory be the root of the zipfile name.  I.e.

foobar.tar  -> foobar/

foobar.zip  -> foobar/

It could be quite distressing to unzip a collection of clipart zipfiles
in a dir, to find all of them writing into the same directory.

> 3.  Within the clipart directory (and any of its subdirectories)
>     there can be any of the following:
>     A.  subdirectories
>     B.  A file called metadata.rdf which contains metadata
>         that apply to all the images in this directory (unless
>         their own metadata override it on a per-image basis)
>         as well as to all the subdirectories (unless _their_
>         own metadata override it on a per-directory basis).
>     C.  SVG images.  These can have embedded metadata, which
>         MUST include any of the required metadata that are
>         not already specified in metadata.rdf.  All SVG
>         images should have the extension .svg
>     D.  Images in other formats (e.g., PNG) with their type
>         specified by a standard filename extension (e.g.,
>         .png for PNG images) and their metadata specified
>         externally in a file with the same base filename
>         and the .rdf extension.  That is, if the file is
>         happy-puppy.png then the metadata must be in the
>         file happy-puppy.rdf.  The image-specific metadata
>         may be omitted only if all of the required metadata 
>         are specified at the directory level in metadata.rdf
>     E.  An optional README.txt (or readme.txt) containing
>         plain-text information about the images in the
>         directory.
>     F.  Thumbnails (optional)
> 4.  Specify a standard extension for these packages.  Some
>     options...
>     A.  azc (for Archive::Zip::Clipart, a probably name for
>              the module that will facilite working with them)
>     B.  oco (for OpenClipart.Org)
>     C.  zcl (for Zipped CLipart)
>     D.  zca (for Zipped Clip Art)
>     
>     I ran these through filext.com and found no extant meanings for
>     any of them.  I also checked 
>     http://whatis.techtarget.com/fileFormatA/0,289933,sid9,00.html
>     and none of them are listed there either.  Then again, neither
>     are .sxw and .sxc and so on listed, so if anyone knows of a
>     more complete list of in-use filename extensions, speak up.
>     
>     Alternately, we could just use .zip as the extension.  Thoughts?

To broaden the applicability of this file format, perhaps we could refer
to it as a 'Zipped Image Library' - 'zil'?

What I'm thinking about is guiding this towards another idea I'm working
on for Inkscape - Symbol Library Extensions - a feature for Inkscape to
allow installing collections of SVG for direct use inside Inkscape
(through a browser).  Since this could be useful for kinds of SVG items
beyond clipart, it would be appropriate to use a more generalized name.

> Now, about thumbnails...
>   
> "Jonadab the Unsightly One" <jonadab at bright.net> writes:
> 
> > 1.  The spec specifies thumbnails should be stored in a .thumbnails
> >     directory inside the user's home directory; we will probably
> >     want to store them in a special directory (may as well be
> >     .thumbnails) within the main directory of the archive -- thus,
> >     probably something like foo.zip:clipart/.thumbnails/normal
> >     rather than ~/.thumbnails/normal
> 
> Unless someone can think of a reason to do it differently, how about
> we just agree that clipart/.thumbnails within the zip archive contains
> things that would go in ~/.thumbnails when the package is installed on
> a desktop system.  That leaves the location hashing...

I could live with this, although having hidden directories within a
zipfile feels sort of wrong.  I'd love to hear other people's thoughts.
I think there's value to following the spec, but if it did not exist, I
would be advocating keeping the thumbnails beside their originals.

> We also should allow for thumbnails to be optional; images don't
> *have* to have thumbnails.  Though when *we* build packages we
> probably should provide thumbnails, if possible.

Yes; for example with Inkscape we will probably have an automatic
preview functionality available, in case of missing thumbnails.

Bryce