[Clipart] Comma-separated keywords in metadata

[Jonadab the Unsightly One]

Bryce Harrington <bryce at bryceharrington.com> writes:

> In Inkscape we implemented a jar-based format for collections of svg
> documents.  Inkview can open and view these types of files.  It uses
> .jar or .sxw as the file extension name.  Someone had suggested
> .inkjar but that got way too many rolled eyes.  ;-)

Is this format suitable for our purposes?  Could we just re-use it?

And isn't a jar just a special kind of zip anyway?  (I know sxw is.)

> If you do adopt a new extension, I'd strongly recommend:
>    * Register it and its mimetype with TPTB

I hadn't thought about content-type.  Should we just use the same
content-type as for ordinary .zip files, or should we use one
specifically for clipart packages?  Maybe Archive/X-Clipart ?

>    * Consider how to generalize the file structure for things beyond
>      our own needs, such as presentations, frame-based animations,
>      etc.

I'd think it would be general enough to serve for any type of
collection, but for many purposes (e.g., a collection of documents) a
regular .zip would do just fine.  I guess it wouldn't hurt to make it
general enough to work for collections of other kinds of reusable
artwork than just images, though -- e.g., collections of sound clips.
Come to think of it, some of the wording of the specification is
probably all that needs to change from what I've posted so far --
e.g., generalizing from "images" to "items" or somesuch.

>    * Discuss it on inkscape-devel, regarding adding support for it

Later.  Right now we're still at the thinking-out-loud stage.

>> >  * Use an extension other than .zip, preferably one that hasn't been
>> >    used for any other very major thing before.
>>      
>>      .oco              Stands for OpenClipart.Org
>>      .ocozip perhaps?  Or should we stick to three letters?
>>      .sxa              (The a stands for "Art"; c is taken for Calc.)
>>      .zca              Zipped Clip Art
>
>        .artz
>        .ocal

The more I think about it, the more I'm not crazy about extensions
longer than three letters.  Any more-than-three-letters extension you
can name has a three-letter equivalent that's used on systems that
only support up to three letters in the extension.  .html becomes
.htm; .jpeg becomes .jpg; .glulx becomes .ulx; and so on.

Now that you mention generalizing for more things than just visual
art, I'm thinking maybe the extension should be rethought in light of
the possibility that the same package format could be used for
collections of sound clips or whatnot.  That's still reusable art, in
some sense, but not quite the same.  I'll think about this some more.

>> >  * Specify what image formats can be in the package.
>>    
>>      .svg of course
>>      .png obviously
>>      
>>      Others?  .gif and .jpg ?  .tiff ?
>
> I'd suggest leaving it open ended if possible.  

Now that you mention it, I agree completely.  We could suggest
_examples_ of the kind of thing that might be included and leave it at
that.

>>      Or should it be permissible to have the directory-wide
>>      metadata cover all of them, with the understanding that when
>>      any images have their own metadata, that overrides the general
>>      directory-wide metadata?
>
> Yes, sounds good.
>
>> >  * Probably wouldn't hurt to specify a LICENSE file.
>>    
>>      /clipart/LICENSE.txt perhaps?
>
> Yes, and allow optionally LICENSE too, since that's common.

Now that I've thought about it further, I'm thinking we require the
licensing to be covered in the metadata.  Do we want to require that
in the package format spec itself, or just for OCAL contributions?

(Obviously, the package format spec itself won't specify what the
license is; whereas, for OCAL we require public domain; but I assume
that other licenses could be specified in the metadata, yes?)

>>      /clipart/README.txt maybe?
>
> Yes, also optionally README.

No, it absolutely should have the .txt extension if it's plain text.
Otherwise it's a royal pain in the neck to open on some platforms.  If
we were developing something only intended to work on POSIX systems,
that might be different, but we're not[1].

> I'm not a big fan of those .xvpics subdirs that tend to show up
> everywhere...  The other approach would be better.

The thumbnails spec says one .thumbnails directory in one place.
We'll have to adapt it to use a directory inside the package, though.

--- 
    
[1] At least, I'm not; my current system is Linux, but I refuse to be
    tied down by any platform-specific applications or file formats; I
    got away from that once and for all when I moved from Pegasus Mail
    to Gnus (at no small inconvenience) to get away from Windows, and
    now everything I use is portable; never again will switching OSes
    mean I have to switch applications or file formats.

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