[Clipart] release

[Jonadab the Unsightly One]

"Stephen Silver" <ocalocal at btinternet.com> writes:

>> You could zip them up in a batch and submit the zipfile (or tarball
>> or whatever).
>
> Well, that didn't work.  The upload script wants more metadata, even
> though every file already has metadata (since they've all been
> through the upload script before).

Oh, yeah, sorry.  With a zipfile, it doesn't try to read individual
metadata for every file, just a single metadata.rdf, which I guess is
not the best solution in this case...

>> Or you could put the zipfile (or whatever) up on the web anyplace,
>> reply here with a URI, and I'll shell into the server and wget it
>> over to incoming.
>
> OK, here's the first batch:
>   http://www.argentum.freeserve.co.uk/repaired-files-1.zip

Okay, we'll do it that way.  I've put that one in incoming.

> That's 44 so far.  

Nice.

> These were mostly ones with MIME separators in them.  

Yes, I figured those would be the easiest to fix.

> I fixed 14 other files with various problems (mostly wrongly encoded
> non-ASCII characters).

I'm glad we've started talking now about how to fix that.  Converting
the text-field strings to UTF8 is something I'm sure there's a module
for, so it should be possible to get that done.

Though, it's taking longer than anticipated to move away from
CGI::Lite, partly due to some unanticipated additional changes I have
to make for it to work right, and partly because I got busy.  (I'm
sure that never happens to anyone else around here...)  So I won't be
checking that change in this week like I'd hoped.

And it won't be until after that that we can work out the non-ASCII
characters thing fully.

> By the way, many of the files in the incoming folder have HASH
> garbage in the keywords - some have no real keywords at all.

I still don't know what causes that.  That's another thing we need to
track down at some point.

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