Last modified: 2009-12-31 01:52:32 UTC
See, for example, http://commons.wikimedia.org/wiki/Debian. The second image in
the gallery is only 87px wide, because the SVG file has a "size" of 87px. This
fake size should be ignored for SVGs in galleries.
If the file specifies 87 pixels as its natural size, then that's what it'll show
as. Gallery thumbs scale down, they don't scale up.
The file does specify this (using generic units, which are ~= pixels):
<svg height="108.445" space="preserve" viewBox="-10 -10 107 128" width="87.125">
I'm under the impression those numbers, height="108.445", width="87.125", are in
*points*, not pixels.
Regardless, the whole point of SVG is that you can scale up. I see no reason
why an SVG image shouldn't be scaled up when used in a gallery. Dismissing the
issue with "wontfix" is simply obstructionist.
'When a coordinate or length value is a number without a unit identifier (e.g.,
"25"), then the given coordinate or length is assumed to be in user units (i.e., a
value in the current user coordinate system). .... One px unit is defined to be
equal to one user unit. Thus, a length of "5px" is the same as a length of "5".'
If the image specifies a natural size that's small, that's because it's *supposed*
to be displayed small. So, that's going to be the size it gets shown at. You can
of course scale it up in an [[Image:foo.svg|200px]] usage if you like.
That standard also states "in most circumstances, "px" units will not map to the
device pixel grid."
Of course, [[Image:Foo.svg|200px]] works correctly. This bug is talking about
the use of SVG in <gallery>s. Currently, the only way to make an SVG display
correctly within galleries is to use an SVG editor to scale it up to 120x120px,
and re-upload the modified version. Naturally, it would be much easier to
simply fix the software to do what users expect.
The image displays at its specified size, unless it is larger than the box can
accommodate in which case it is scaled down to fit. That's how all images work,
and is the natural, expected behavior.
Just because you can scale doesn't mean you always should.
(In reply to comment #5)
> That's how all images work, and is the natural, expected behavior.
How do you know that's the expected behavior?
Compare [[Image:Commons-logo.png]] and [[Image:Commons-logo.svg]]. The PNG
version looks bigger. 99% of people will erroniously conclude that the SVG
version is a thumbnail of the PNG version, and that the PNG version should be
used in favor of the SVG version. Indeed, the SVG version was tagged as
"redundant" to the PNG once already (see
The confusion could be avoided by displaying the SVG logo on its image
description page at the user's selected image size.
> Just because you can scale doesn't mean you always should.
Actually, I think it does. If we could scale up PNG or JPG images, it would be
preferable to do so. We don't do that simply because there is no good way to
scale these file types up.
Morally speaking, SVG files have infinite resolution. The promise of SVG is
that it finally frees us from having to worry about resolution issues. As long
as MediaWiki refuses to scale up, this promise remains unfulfilled.
I would tend to agree that SVG images can be assumed to be scalable up or down to any size regardless of their "native" resolution, just because they're SVGs. This assumption may of course fail in some cases, such as with embedded bitmaps, but it seems safe overall.
Then again, I have to wonder if the behavior of not scaling up images in galleries altogether is reasonable (bug 13214). At any rate it makes no sense for this to be closed while that's not. It seems now that that's going to be fixed, so I'll just mark this a duplicate.
*** This bug has been marked as a duplicate of bug 13214 ***
Changing to FIXED since SVGs are now scaled up in galleries.
bug 13214 seems to be about not scaling up small bitmap images