[Clipart] Thumbnails in clipart packages

[Jonadab the Unsightly One]

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?

-- 
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/