[Clipart] Comma-separated keywords in metadata

[Jonadab the Unsightly One]

"Jonadab the Unsightly One" <jonadab at bright.net> writes:

> Tobias Jakobs <tobias.jakobs at web.de> writes:
>
>> Yes, there is the "Thumbnail Managing Standard"[1] from
>> freedesktop.org.
>   
> Ah.  I'll have a look at that.  If it meets our needs, we should use
> it in preference to a different spec (e.g., copying some application's
> behavior or making up our own).

We'll need to make some adjustments to compensate for the fact that
this specification is clearly intended only to deal with files stored
on a desktop user's hard drive; we need to deal with files in a
package or archive.  This means a couple of things...

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

If all that sounds too complex, we could make up our own scheme for
where to store the thumbnail within the package.  As long as it's a
128x128 PNG image, tools aware of our package structure should still
have an easy time unpacking these thumbnails and storing them where
the thumbnail spec says they should go.

Which way should we go?  Is it more useful to make some modifications
to this thumbnail-storage spec and attempt to use it, or should we
just make our own spec for thumbnails within clipart packages?

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