On 26 June 2012 19:16, Achim Flammenkamp achim@uni-bielefeld.de wrote:
Thus I dig done the problem and it seems to be out of my reach to correct this miss-design by wikimedia but identified it to got founded in some wikimedia politics or history which now noone seems to be responsable. :-/
There are no politics involved, there is just misunderstanding of your point, which is something completely different. Calling things 'miss-design' will also not get you helped to get this solved - we are not your enemy.
If there is a SVG-file on wikimedia, some fixed logic generates png-images for the flag's description page generally. The first image, here 800 × 457, is displayed very prominently always at the beginning of the SVG-description file, others (320 × 183 pixels | 640 × 366 pixels | 1,024 × 585 pixels.) follows as links. All these sizes seems to be bounding-boxes from historic used (maybe even today) resolutions of (CRT-)monitors respecting aspect about ratio as near as they can If horicontal OR vertical is maximized to this resolution. Then some facts to the original SVG code is stated and than further fixed png-sized images follows as links (This image rendered as PNG in other sizes: 200px, 500px, 1000px, 2000px.).
Yes. Essentially, you have to choose *a* size, and they might as well be these. The problem you are encountering is a more generic one - even though SVG images are scalable, you will always have rounding issues.
This flag should have a ratio of 7:4 which has the SVG original, but NOT the prominantly displayed first image (800 × 457 , 800 is not divisible by 7, nor 457 by 4)!
When speaking about the ratio of a flag, I was understanding it was rendering at, say, 5:4 instead of 7:4. Instead, the problem is the rounding, which makes the aspect ratio 1.7505... instead of 1.75. That, on itself, is not a large problem.
And because the Tekbirs should be exact aligned at the border of the green/white and red/white strip rounding errors may provocate a green or a red one-pixel-thick line to appear between the white strip and the Tekbir as you see in the 800x457 image!
So the problem is the SVG is rendered incorrectly when such an aspect ratio is chosen.
I also tried different work-arounds but got no satis- factoring solution, because it is not a coding issue in SVG!.
Although any SVG renderer should be able to render any SVG file to any resolotion in a correct way, this is of course not the case. I don't know the specifics of the SVG renderer used, but I suspect there may be different methods to specify the same results - some giving the correct result at all resolutions, some not.
Moreover to avoid further artifically introducted problems by chosen thoughtless fixed sizes (500px), I propose NOT to use multiples of 100 or 1000 nor historican monitor sizes as fixed image sizes (which are out of control for the user/uploader!!), but sizes which consists on many small primes, i.e. HCN (highly composite numbers).
I don't see how HCN's would solve this. It makes much more sense to calculate the sizes that are close to the target value (which can be the same as currently), but with the exact aspect ratio. So instead of 320 x 183, one would get 322 x 184. However, it's still a workaround: we really should have an SVG renderer that 'does the right thing'.
In bugzilla, there is a 'tracking bug' (a bug that lists other bugs) on SVG rasterization issues [1], but I could not find a bug related to this (also not via the search [2]), so it is probably a good idea to open a bug for this. In the meanwhile, I think there are three workarounds:
1) update the description page to list alternate sizes that do render correctly (which I just did [3]). 2) upload a PNG version and link to that from the SVG version 3) fiddle with the SVG until the renderer used correctly interprets what you want - maybe someone with a lot of SVG-fu can do that for you.
Best, Merlijn
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=8901 [1] https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=svg&list_id=12575...