[Clipart] Thumbnails in clipart packages

[Jon Phillips]

Cool, maybe you should post this extensive email to the wiki for any
tweaking of the proposal.

Jon


On Fri, 2004-07-16 at 16:40, 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
> 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?
> 
> 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...
> 
> > 2.  Wherever the spec talks about a file's location, it speaks of an
> >     absolute uri (e.g., file:///home/foo/file), which will obviously
> >     not do for files that are stored in a package that's being
> >     transferred over the internet.  We'll have to work out some
> >     substitute scheme where the file's location can be relative to the
> >     package (zipfile) in which it is packaged.  Thus, instead of
> >     file:///home/someone/foo.svg we'll have something more like
> >     ocopackage://clipart/foo.svg or somesuch along those lines as the
> >     file's canonical location.  (When a thumbnail-aware tool
> >     unpackages the clipart, it will obviously have to recalculate this
> >     (and redo the md5 hash for the thumbnail filename, and replace the
> >     thumbnail's PNG metadata that says what file the thumbnail
> >     represents) based on where it is putting the file.)
> 
> How about the following:
> 
>  * use clipart:// as the URI scheme for files inside a clipart
>    package (analogous to file:/// for files on the filesystem).
>  * omit the toplevel clipart directory from the URI, since
>    everything in the archive is inside of that, so it would
>    be redundant.
> 
> So, if we have an image /clipart/buildings/fire-station01.svg
> in the zipfile, then its location would be coded as follows:
> clipart://buildings/fire-station01.svg
> 
> The filename of the thumbnail would be calculated from that based on
> the MD5 hash just as the thumbnails specification indicates.  When
> clipart-package-aware software installs one of these packages, then,
> it would see /clipart/buildings/fire-station01.svg, translate that to
> clipart://buildings/fire-station01.svg, hash that, find the 128x128
> thumbnail in /clipart/.thumbnails/normal/somebighash.png, (and/or the
> 256x256 one in clipart/.thumbnails/large/somebighash.png) and then
> store that thumbnail on the user's system according to the thumbnails
> specification (rehashing its filename based on the new, installed
> location of the image).
> 
> 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.
> 
> Comments?  Suggestions?  Snide remarks?
-- 
Jon Phillips

PO BOX 948667
LA JOLLA, CA
92037
USA

USA.PH.858.361.2811
jon at rejon.org
http://www.rejon.org

Inkscape (http://inkscape.org)
Open Clip Art Library (www.openclipart.org)
CVS Book (http://cvsbook.ucsd.edu/)
Scale Journal (http://scale.ucsd.edu/)