So, the aspect ratio is right. Your problem is that you want it to be a
perfect multiple of 7:4.

(...)
> Detailed explanation at example:
> 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.
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).

> 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.).
> 
> The last , in small font set explanation, I added for people to get an 
> understanding of the reasons lying behind the scene. :-/ [Only for thios 
> flag].
> 
> 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)!

So nobody should be allowed to get a thumbnail with eg. exactly 120px
width? (As used in the galleries, meaning you would end up with
differently-sized thubmnails, which would look bad)


> Because in this flag, there are these two strips of "Alkmar Allah" Tekbirs,
> rendering artifacts can get easily visible if improper rendering occurs!
> First reason is: flag height in pixles is not divisible by 3, so the three
> green, white and red strip can't be of equal height (as demanded in the 
> original
> SVG-code)! 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 your problem is not the scaling itself but that it gets wrong (I
don't see a red line above the letters or a green one below them, btw so
seems to render fine).


> It seems the scaling and rendering is doing in the
> wrong order (my guess, I also tried different work-arounds but got no satis-
> factoring solution, because it is not a coding issue in SVG!).

We are just asking rsvg to "render this svg in this size", not doing two
different passes.


> I guess: IF one would FIRSTLY render the original SVG to its orignal size into
> a fixed bitmap format and then scale this down to the wanted (png-)size,
> several visibale artifacts (like the just mentioned MUST be gone!). So, this 
> is
> a rendering-design issue. 
Well, if the given instance renders badly you should take the issue
upstream to rsvg authors (unless the problem is that wikimedia is using
an outdated version).


> 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). Thus my second
> pointer in my first email to explain the background.
I'm pretty sure this will turn out to be a bad idea, but please propose
the alternative sizes.


> BTW: The same effect/statement is correct for SVG-templates like the one which
> uses national flags displaying in info-boxes in articles. But here maybe I can
> trigger guys responsible for these templates on XY-wikipedia (language 
> specific).

Those templates usually request a fixed size, so not related to
MediaWiki defaults.


> I hope I have explained it righlty and (nearly) relevant completely now. 
> 
> Thanks for your attention,
> Achim

Thanks for your explanation.


_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to