https://bugzilla.wikimedia.org/show_bug.cgi?id=14268
--- Comment #10 from Brion Vibber <[EMAIL PROTECTED]> 2008-11-21 18:09:49 UTC --- (In reply to comment #9) > I'll add another case for you to consider. I can only follow part of your > discussion, so maybe it's simply that I don't understand which code version > you > are running. Is it still the 'crappy hack'? > http://commons.wikimedia.org/w/index.php?title=Image:Arbeitslosenentwicklung_1933.svg > is encoded as UTF-16, and this currently leads to no PNGs being rendered. Yeah, I think so -- the original checks would get confused by UTF-16 since it's not ASCII-compatible. A proper XML parse should work fine as long as the file's legit. (Unfortunately the referenced file has been deleted so I can't test on it.) (In reply to comment #8) > (In reply to comment #4) > > Since XmlTypeCheck already handles those two cases, and there currently > > exists > > no other requirement which the SvgInfo class actually handles, my > > recommendation still stands to add a root attribute accessor to XmlTypeCheck > > and use that in place of the SvgInfo class. This would accomplish all > > required > > goals with less code and less code duplication, increasing reliability and > > maintainability of the code. > > > > An accessor was added in r41024, so we're no longer accessing $rootElement > directly (needed updates to MimeMagic too). One more step in the right > direction. My recent changes to XmlTypeCheck to accept an element filter (used for more thorough scripting security checks on upload) should make it real easy to plug this into the existing class now. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
