This is because there's currently a rendering limit of 1024 pixels set.

info wrote:

Aha, I understand. Then is it not an option for SVG images (which are scalefree) to set the img tag size (<img width=... height=...>
to 1024 if the actual "size" (dimensions of the SVG document) are greater than these 1024 pixels. This solves the problems of ugly
jagged because scaled images in the preview, and in my view, does not introduce any problems. (The only problem of scaling down
pixel-sized structures to sized of less than one pixel is not valid as it is introduced by scaling to max 1024 pixels anyway.)

We don't support inline SVG at this time, only rasterized.
When inline SVG is supported, they will of course be client-side scaled.
Closing as INVALID again.

info wrote:

Well in the image description screen (the "wikiX.tld/wiki/Image:test.svg page) you DO have an inline SVG which is invalidly scaled. As
most users see this screen first when they upload the image, and see it severely jagged, they think the image is b0rked and upload
a .png instead (I am the "SVG authority" on the dutch wikipedia, at least 2 people told me they saw their SVG's were jagged and uploaded
a PNG instead - undesirable behaviour IMHO). This can *easily* be fixed: the <img> tag in the image page should just show the
width/height of the rendered image instead of using the .SVG sizes and invoking the client scaler. This is a waste at SVG scaling yields
much better results than upscaling of PNG.

Besides, for SVG images much bigger than 1024 pixels, you allready do this. For exampe:
http://nl.wikipedia.org/wiki/Afbeelding:Spoorlijn_Groningen-Delfzijl.svg is rendered to 877x1023 pix and the image tag also reflects
this size. Correct behaviour! (the underlying SVG is 300000 pix wide).

info wrote:

Sorry, wrong understanding of the word "Inline" from my side. I'm not talking about inline SVG at all. I'm talking about the displaying
of the PNG rasterized from the SVG.

What happens is that mediawiki generates a PNG of size X,Y where X,Y=<1024. Yet, the <img> tag in the image page gives a width/height
of > 1024 (1052 in this case) - information it got from the SVG document size <SVG:SVG width="841.88977pt"> which is 1052.36 px.

Yet, for other images over 1024 px, you do get the width/height in the <img> tag <= 1024 where the source file is bigger!

This is, IMHO, different behaviour in two simialar cases, hence, a bug. The <img> tag should *not* specify a size greater than the size
of the rasterized PNG (=1024 right now), unless the user specifies it as such.

Assigning SVG bugs to Ariel -- need a cleanup pass to see what's fixed up by a librsvg upgrade, what can be resolved with fixes to our font configuration, what can be fixed on our end, and what still needs to be pushed upstream.

Image has nominal size 1000x1000

Pref size: 800x600
<img alt="Bestand:Honkbalposities.svg" src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Honkbalposities.svg/800px-Honkbalposities.svg.png" width="800" height="560">

Pref size: 1024x
<img alt="File:Honkbalposities.svg" src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/50/Honkbalposities.svg/1000px-Honkbalposities.svg.png" width="1000" height="700">

Seems this issue is fixed. No idea when.