[Clipart] KDE and OCAL

[Nathan Eady]

Aaron Seigo wrote:

> yes, that makes sense. do you have a DTD in mind for this or should i see if i 
> can recruit one of our XML freaks to help out here? in fact, i have someone 
> in mind.. let me email them and see what their interest level is, if any.

I had a vague idea how the XML would look (something vaguely like what
follows) but no formal DTD.  Just something along these lines (view this
as just a seed for discussion)...

<clipartindex language="en" hierarchy="hierarchy-en.xml">
<collection "Open Clip Art Library" version="0.15">
   <images>
      <image id="00165293"
             src="animals/mammals/dog_head_nicu_buculei_01.svg"
 
thumbnail_normal="animals/mammals/dog_head_nicu_buculei_01.png" />
      <image id="00238237"
             src="animals/bugs/bug_nicu_buculei_01.svg"
             thumbnail_normal="animals/bugs/bug_nicu_buculei_01.png" />
   </images>
   <keywords>
      <keyword name="animal">
         <image id="00165293" />
         <image id="00238237" />
      </keyword>
      <keyword name="mammal">
         <image id="00165293" />
      </keyword>
      <keyword name="insect">
         <image id="00238237" />
      </keyword>
   </keywords>
   <authors>
       <author fullname="Nicu Buculei" username="nicubunu">
         <image id="00165293" />
         <image id="00238237" />
       </author>
   </authors>
   <titlewords>
       <titleword name="dog" />
         <image id="00165293" />
       </titleword>
       <titleword name="head" />
         <image id="00165293" />
       </titleword>
       <titleword name="bug" />
         <image id="00238237" />
       </titleword>
   </titlewords>
</collection>
</clipartindex>

Note that the thumbnails will need to be 128x128 (rather than 80x80
as currently), in accordance with the f.d.o. thumbnail spec.  As far
as storing them locally in the appropriate location when unpacking,
I think we can let the unpacking app do that; for users who just
unzip the thing with no knowledge of the file format details, the
thumbnails will still be there, and it will be obvious which ones
go with which images, so for file browsing purposes and so forth
they will be usable as they stand; hashing filenames would destroy
that, and putting them in directories whose names start with periods
is not really portable; again, the unpacking app can do that if
it is aware of such issues.

Also note that thumbnail_normal refers to the "normal" size in
the thumbnail spec; thumbnail_large is an obvious correlary,
albeit one that I think at present will go unused, as 128x128
seems to me quite large enough for thumbnails in 2005 (assuming
we fix the document bounds as appropriate so that the thumbnails
make good use of that space).

I am of two minds about titles, regarding whether they should be
handled as title words (like above) or full titles (one entry for
each image).  In the latter case, having them in a dedicated
section seems redundant; they could be made attributes on each
image element.  Hmmm.  Thoughts?

>>Note that for the *thumbnails*, the f.d.o. thumbnail spec specifies
>>a location for those, which would be different from where the images
>>themselves would be put (i.e., it is intended to be a dedicated place
>>just for thumbnails).  Also the filenames of the thumbnails are to
>>be constructed based on where they are put in the filesystem, so that
>>would have to be done at install time, when unpacking.
> 
> this is probably the preferred, but not the only mechanism. the spec also 
> allows for local storage of the thumbnails to allow things like CD-ROMs to 
> come with pre-created thumbnails that don't need to be installed.

Ah.  I somehow missed that before.  (Maybe it is an update?)  Still, I
think with our situation, we want the package to be able to be unzipped
(or untarred) and used as it stand by users with only naive unpackaging
tools; with the index, I don't think that inhibits in any way the
ability of a thumbnail-spec-aware unpacking tool to put the thumbnails
in the locations the thumbnail spec discusses.