[Clipart] release

[Nathan Eady]

Stephen Silver wrote:

[Note:  sorry for the duplicate copy, Stephen; I keep forgetting that
my mail client at work doesn't support the options I'm used to at
home, such as all replies to messages in a given folder going to
a given address.]

 > They are broken by leaving in MIME separators (looks like a CGI::Lite
 > bug) and by mishandling of non-ASCII characters and of ASCII
 > characters that need to be escaped in XML.  There may be other
 > things too, but these are the most obvious.


Yes.  The MIME separator thing, I believe I know how to fix.
I'll replace CGI::Lite with something else.  As an added bonus,
we will gain the ability to inspect the user-supplied filename
to see what the extension is, so that we can avoid needing
to ask the user for the filetype if it's obvious from the
filename.  I should be ready to check in this change later
this week, but I want to test it with several browsers first
and make sure I'm not screwing anything up.

The Unicode characters are another thing; I'm a little out of my
depth on that one.  It seems very strange to me that a web browser
would send part of the form data (the XML file) in one encoding,
and other parts (e.g., the author) in another, different,
incompatible encoding.  That feels like a browser bug to me, or
perhaps a fundamental design flaw in the unicode standard, but
probably I just don't know what I'm doing; probably, the real
problem is that I don't know jack diddly squat about Unicode.
(But, IMO, if Unicode were well-designed, I wouldn't *need* to
understand its inner workings, because my code is NOT changing
the way any of the characters are encoded; it's just taking
them the way the browser sends them, and storing them together
in a file on disk.  The fact that this breaks things makes me
want to defenestrate Unicode and ask people who can't get by
with ASCII to design a *sane* encoding for their non-ASCII
characters.  </grump>  Since that's not really a viable option,
I suppose what we really need is for a Unicode guru to explain
to me what my code needs to do to work around this issue.)

[Images that were already broken by upload.]

 > I think we should start fixing them now.


If it's as simple as deleting everything after </svg> and they'll
magically be just fine, that's definitely worth doing now, yes.

 > I just need a way to get the files into the release process
 > without going through the upload script again.

You could zip them up in a batch and submit the zipfile (or tarball
or whatever).  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.

 > But as well as fixing them we should also make it obvious that they
 > *are* being fixed.  When someone spends a lot of time creating an
 > image, and OCAL apparently just discards it without explanation
 > or obvious reason, it's likely to put them off ever contributing
 > again.


Perhaps a news item on the front page, to the effect that we're
correcting a problem caused by our upload script and rescuing a
number of previously-submitted images that failed due to this?
It would be nice to have a number to put on the announcement.

 >> Are the broken images all contained in the 0.11 or are there
 >> multiples ones for the past releases? What I'm getting at is
 >> if we are dragging along broken images along each release or
 >> are there broken ones elsewhere that we need to fix.
 >
 >
 > They are not usually dragged along from previous releases.  There are
 > over 200 different SVG files in the failed-file zips that Jonadab made

I am sure, by the way, that not all 200 are rescuable.  Surely some
of them are, however.

 > for releases 0.09, 0.10 and 0.11.  I don't know what has happened to
 > the failed files from release 0.08 and earlier - perhaps they have
 > been lost entirely.

We may still have at least some of them in the incoming-pre-0.nn
folders from before the big server problem, but if so they would be
mixed in with images that did not fail.  However, the PASSFAIL
and/or LOG files from the releases in question may be useful for
identifying them.