[Clipart] uploader problems

[Jonadab the Unsightly One]

Nicu Buculei <nicu at apsro.com> writes:

[Excess junk after </svg> that looks like content-separator stuff]
>> Indeed.  I can't tell for sure, but this looks like it could
>> potentially represent a bug in CGI::Lite or else the file could
>> have been corrupted before it was uploaded...  We should watch for
>> this, to see if it happens repeatedly.
>
> this was happened before, see
> http://www.openclipart.org/incoming//failed/flourish_three_lower_left_corner_01.svg
> http://www.openclipart.org/incoming//failed/flourish_three_upper_right_corner_01.svg

Okay, I think I know a way to work around this problem in the upload
script.  Assuming there's no valid reason ever for anything to come
*after* the closing </svg> tag (right?  Someone who knows more about
the SVG spec than I do feel free to comment here), the upload tool can
just strip off anything after that without ruth.  Unless someone comes
up with a reason why it shouldn't do that, I'll just go ahead and make
that change next time I update it.

However, this will only work around the problem for SVG.  If extra
junk gets somehow appended on the end of some other file type, I don't
know what will happen.  But SVG is the most common upload type, so I'm
thinking we should at least fix that since we can.  Yes?

>> Currently, the uploader does not make any attempt to second-guess
>> what filetype the user says a file is; it just takes the user's
>> word for it.
>
> SVG::Metadata not return an error when writing XML metadata in a not
> XML file?

SVG::Metadata actually doesn't write the metadata into the file; it
just supplies a to_rdf() method that I call to get the RDF stuff,
which then gets inserted right before the </svg> tag.  Come to think
of it, if the string '</svg>' does not occur in the file, then the
metadata will not be inserted.  It would be possible to test the
return value of the substitution and issue a warning or error if this
happens.  I'll put that on my TODO list.

As far as when parsing existing metadata, it fails to find it if there
isn't any, but it fails in the same way for a metadataless SVG as it
would for a misfiletyped PNG, I think -- which is okay; it shouldn't
be SVG::Metadata's responsibility to verify that the file it's working
with is indeed an SVG image.  If anything, the upload script should be
smarter about that, but in the interest of getting a usable version up
quickly I didn't bother with that initially.  It's the sort of thing
that shouldn't be too hard to retrofit, assuming we know how to do it.

For SVG, this should be pretty easy:  if the strings '<svg' and
'</svg>' (case-insensitive?) don't both occur, then we can be pretty
sure the file is not an SVG image.  I'll add a TODO for this too.

Some of the other filetypes may be trickier to autodetect/verify, but
again, if we can figure out how to do it (in an acceptable amount of
time), retrofitting that functionality into the upload tool will be no
problem.

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