On 26 June 2012 19:16, Achim Flammenkamp <achim(a)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=1257…