eady at galion.lib.oh.us
Tue Mar 8 14:42:08 PST 2005
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
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
More information about the clipart