Hi
By pressing the 'edit' button - it's just part of the page text. I removed the entire section, as Ryan solved the issue.
Yes, I agree this issue is NOW "about" completely solved for this Flag of Iran on commons-wikimedia.
May I give a summary/conclusion of the over-all subject/topic? [rhetoric ask]
1) There are surely other geometric designed objects which are coding as SVG-files. Thus there can and will happen the same issues as for this example as long as the used SVG-renderer renders in such a way and the object has coincident horizontal or vertical lines. The actual work-around needed in the specific case will always be a very special solution (if possible and known).
2) I wonder why the SVG-graphic devolpers use such an "improper"(?) rendering- philosophy. All these articfacts on the Iran-flag would have been avoided, if the rendering is divided up logical into two steps: Firstly render the SVG-code to the size given in this SVG-code (or an integer multiple for large final sizes) to a pixel (discret) map. And then scale this pixel-image down to the just wanted size. For this step there already exist proven good algorithms since many decades. No need to reinvent the wheel and this buggy in the early SVG-versions. :-( If you are clever you may connect these logical two steps into one practic pass if this if less resource- or time-consuming. But NOT choose a cheaper rendering-variation which give worse final images. :-(
What is the sense of these width and height absolute values in the svg-statment? I used them as a hint for proper/better rendering -- for the image description these are of no use; there we have the better viexbox-information.
3) Probably one should mail this proposal/question/idea/opinion to the different SVG-render groups (librsvg/inkmagic,Inkscape or whatever you know) -- this is not a wikimedia-developer issue. Of couse they could install a work-around by rendering every SVG-file first only to the default SVG-size and then use a scaling with a proven good pixel-renderer to the wanted image size.
4) I cite form a first reply "Those links as provided as convenience for downloading smaller versions. They were added per bug 2581. I think those were added as arbitrary sizes (with a large history usage, as noted)." I read the whole discussion of "bug 2581" at https://bugzilla.wikimedia.org/show_bug.cgi?id=2581. I cite a central point: "I think that should be configurable at LocalSettings level, not at MediaWiki:" Thus this may be justified to be called a "subjective decision". :)
5) I would have expected that only the image is displayed at the given original SVG-file size when displaying [[File:*.svg]]. Else each other arbitrary size should be justified why exactly this size is proper for this SVG-image. Thus I called these "improper default sizes" :) And because these are secretly hiden of changing, and noone could tell me how or who can change this (I even get the hint not to change them), I used my wording of "wikimedia politcs". :) Here another (important?) decision is pending! I think I will open a new topic for this issue, which is some weeks older than this "SVG-to-png render problem".
Finally, have a thought or two to the listed 5 points. For me, I think I should finish this issue. Thanks to everbody who helped -- hopefully it need some time before *I* stumple across the next miss-rendered SVG-image and find a good work-around as long as we haven't a better SVG-render-algorithm on wikimedia.
Best, Achim