Last modified: 2011-12-24 16:48:56 UTC
https://secure.wikimedia.org/wikipedia/commons/wiki/File:Sulfamerazin.svg When I uploaded this file was fine. Then MW was updated and after a purge the black lines disappeared from the formula. Then I added stroke="black" to those elements that should be black et voila- it is visible again. Even if this probably intended behaviour, I would like to know. In this case please help me writing a bot or something to fix it for all affected files uploaded before MW 1.18 The same is true for * https://secure.wikimedia.org/wikipedia/commons/wiki/File:Phenanthrene_Clar_rule.svg * https://secure.wikimedia.org/wikipedia/commons/wiki/File:Anthracene_Clar_rule.svg * https://secure.wikimedia.org/wikipedia/commons/wiki/File:Clar_rule.svg and maybe lots of other chemical structures created by Marvin with Batik SVG Generator.
This resulted from the upgrade to rsvg that happened between deployments, not MediaWiki. Using rsvg 2.16.1 to produce a png from that file (with stoke="black" removed), I got one with black strokes. Switching to rsvg 2.34.1, the pngs were produced without black strokes. Resolving invalid because the bug was created upstream. We get a lot of benefits from the rsvg upgrade and are not likely to downgrade.
(In reply to comment #1) if such changes are done the established file based should be assessed before the deploy and fixed before if there are many files same like with the exif jpegs - appearance changed of old files... fucks up everything
(In reply to comment #2) > if such changes are done the established file based should be assessed before > the deploy and fixed before if there are many files I agree that these sort of changes should have better testing in the future. For that, we'll probably rely on community members like you.
Adding Brion who may have some additional thoughts on whether rsvg's new implementation is correct or not. It does look like a bug to me given that Chrome and Firefox are both rendering the SVGs correctly. If it's a bug, we should report it upstream and downgrade if its impact is severe.
(In reply to comment #3) > For that, we'll probably rely on community members like you. Well, I am not a free pre-alpha tester with unlimited time, so do not stress the "rely" too much. ;-) Btw: All community members are already alpha version testers for Mediawiki. The devs and the people who deploy should simply think more about what they do. Wikimedia shouldn't cry about loss of volunteers if they are throwing new bugs at them every week. Oh, and regarding the svg thing: do you know how great such changes are when you are trying to get people to urgently use svg instead of png or even jpeg? Such interpretation changes without a pre-deployment notice and fix (a fix bot for such syntax problems could help) of existing files are priceless. That is not a comment specific to this bug - but on the svg handling at Wikimedia in general.
Not sure about buginess of this specific feature, but a good reminder that we need better acceptance tests for rendering changes. On general principle I'd recommend we set up a batch rendering system that'll run over thousands of images in actual usage and compare the rendering between rsvg and various browsers; where they differ (among each other or among previous versions) that'll help us look for problematic places, either filing bugs or recommending workarounds.
(General thing to consider though is that we *do not* have any control over rendering behavior of browsers, and have only limited control over the rsvg behavior in that we can patch it, control what fonts are installed, and control when/how/if we update it. For the most part, updating rsvg fixes large numbers of bugs -- if it introduces a couple new ones too that's unfortunate. Where we can catch those ahead of time, that'll be a plus.)
It sounds like a regression on this bug: https://bugzilla.gnome.org/show_bug.cgi?id=332700 The rsvg 2.34.1 I have locally however renders both that image and the https://secure.wikimedia.org/wikipedia/commons/wiki/File:Phenanthrene_Clar_rule.svg image as well as https://upload.wikimedia.org/wikipedia/commons/archive/5/55/20111222014913!Sulfamerazin.svg as expected (with black strokes). I cannot locally reproduce Mark's results... Mark, can you provide the exact files & command-lines you're testing?
(In reply to comment #5) > (In reply to comment #3) > > For that, we'll probably rely on community members like you. > > Well, I am not a free pre-alpha tester with unlimited time, so do not stress > the "rely" too much. ;-) Btw: All community members are already alpha version > testers for Mediawiki. I am sorry I wasn't clearer. I meant that we should get your input to figure out what to test since you will find areas that wouldn't occur to us.. And then, yes, *we* should do a lot of the testing beyond just throwing changes on the community. Beyond that, we should make test wiki deployments before we go full production. I hope that wmflabs will help stage rollouts here.
Test wiki deployments are unlikely to help, as the vast majority of images will not change rendering for the worse; the likelihood of just happening across one that fails without an automated test plan is small.
(In reply to comment #8) > I cannot locally reproduce Mark's results... Mark, can you provide the exact > files & command-lines you're testing? Further testing shows that it does not work. I was mistaken when I said I had removed the stroke="black" bits. For what it is worth, librsvg2-2.16.1-1.el5 on Centos 5.6 was the one I thought that I found working. Bug 10207 says we were using a customized librsvg. Maybe there is something else happening and when Bug 24000 was completed, some of those customizations were lost.
Just to summarize and make up for my own confusion: The original upload had a root "stroke" attribute that was supposed to be inherited by its children. The rsvg on Commons does not respect this and results in images like those PNGs supplied for https://commons.wikimedia.org/wiki/File:Test_svg_upload_for_bug_33323.svg Stock rsvg (The centos version in Comment 11 and 2.34.1-2 on my Ubuntu laptop) respects the root element's stroke attribute. In discussing this with Brion on IRC, the problem is probably *not* caused by missing custom patches and it would probably not be caused by MediaWiki 1.18. Still need to track down the cause.
just tested librsvg2-bin 2.26.2-0ubuntu1 from Lucid and got the problem described in this bug. This is probably the version installed on commons... now going to look for upstream bug reports.
Aha -- so a regression that's been since fixed? Needing another update... blarf!
Where I can find the actual version of librsvg which use Commons? *** This bug has been marked as a duplicate of bug 31122 ***
(In reply to comment #15) > Where I can find the actual version of librsvg which use Commons? If you just wanted the binary: http://packages.ubuntu.com/lucid-updates/librsvg2-2 We're going to be compiling our own since moving to that version lost some patches we've made to librsvg. I don't see where the package list or any custom source is pointed to, but you *should* see the current configuration of the renderers by looking through https://wikitech.wikimedia.org/ and https://noc.wikimedia.org/
