[Clipart] Thumbnails in clipart packages
bryce at bryceharrington.com
Sat Jul 17 22:11:51 PDT 2004
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
> F. Thumbnails (optional)
> 4. Specify a standard extension for these packages. Some
> 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
> 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.
More information about the clipart