So what's happening is that making it 41px wide is not tall enough, but 42px wide is to tall, so MediaWiki compromises and makes it 41px wide, but tells the browser to scale the height to be 100px, in order to be close as possible.

Work around is to just use [[Datei:NowCom2010-Q-2.svg|x99px|right]].

Making it possible for the images to be scaled with a height that's correct down to the pixel seems like it would introduce quite a bit of complication for something that is not really applicable very often.

(In reply to comment #0)

Results in a bad scaling (Commons circle looks broken) of the image in my FF10.

I'm confused. What exactly do you suggest we should do?

saibotrash wrote:

(In reply to comment #2)

(In reply to comment #0)

Results in a bad scaling (Commons circle looks broken) of the image in my FF10.

I'm confused. What exactly do you suggest we should do?

Let the server scale it to this height (but not advise the browser to do so). The thumbnail should be scaled to the dimension which is written to html. That would not introduce bad artifacts since the server has the full image as source available (the browser only has the thumbnail available and may use simple scaling algorithms like "nearest neighbor").

I guess, the problem is that there is probably(?) no interface to request thumbnails with a height specified at the scaling servers. Only requesting thumbnails by width is possible. So my previous request is not possible. So this bug maybe could only be a LATER since the interface to the scaling servers is too less powerful.

Another option: do not write a height to html which is not served as image. Problem: the user specifically asked for this height.

saibotrash wrote:

"broken" commons logo

Attached:

saibotrash wrote:

correctly scaled to 41x100 with GIMP based on a 1000px rendering (cropped afterwards)

Attached:

saibotrash wrote:

It would be nice to know that the requested height is not really available and that a bad compromise is used. Then the wiki page author could choose another height. But I have no idea how this message could be brought to him.

[mid air collision]

I guess, the problem is that there is probably(?) no interface to request
thumbnails with a height specified at the scaling servers. Only requesting
thumbnails by width is possible

That is correct in the current code. (OTOH support for adding arbitrary new
parameters seems to be there, so its quite possible it wouldn't be difficult to
change that)

Another option: do not write a height to html which is not served as image.
Problem: the user specifically asked for this height.

There's also things going the other direction where one wants to scale a very
narrow image to some height, and the scalers en up scaling it too high. As a
matter of fact, I think the writing the differing width in html is relatively
new behaviour ( bug 28076 possibly)

Yes, the stored filename and all indexing for the thumbnail are width based. This means that we can't distinguish between multiple thumbnails with different heights but the same (rounded) width. This is a pretty fundamental limitation of the current code, but also a good way to prevent unnecessarily proliferation of thumbnail variants.