robchur wrote:

*** This bug has been marked as a duplicate of 495 ***

ayg wrote:

This is not a dupe of bug 495. 495 dealt with allowing thumbnails to be
specified relative to the *display* width, this asks for them to be specifiable
relative to the *user's chosen default thumbnail width*. The latter is easily
accessible to the software and so the reasons for wontfixing 495 don't apply
here; the thumbnail would still be displayed at its rendered size, with nothing
left to the browser.

(This is disregarding the last line, which is the same as 495.)

robchur wrote:

Let's see a clear, fully-described example of where this would be used and what
sort of markup you have in mind for it, then. If I say I want thumbnails to be
200px wide, then I don't want some editor at the other end deciding I need it
scaled up 200%.

z9z8z-wps wrote:

While Bug 495 is about percentages related to the display width this is mainly for percentages based on the default width which should be
easy to implement. If the other isn't feasible forget about "values relative to the current display width" above and consider "values relative to
the default size".

Example:
The standard thumb sizes are currently 120, 150, 180, 200, 250, and 300 pixels. If an article editor chooses to display a thumb explicitly 300
pixels wide to make it stand out and my standard setting is already 300px I wouldn't see a difference. I'd rather expect to see it scaled relative
to my settings which would be 500 pixels wide for this thumbnail.

One solution would be to scale all explicitly given thumb sizes according to the users settings but that would mean that these absolute sizes
wouldn't be that absolute any more. The better (and easier) solution is to avoid absolute sizes and use relative sizes where possible.

ayg wrote:

(In reply to comment #3)

Let's see a clear, fully-described example of where this would be used and what
sort of markup you have in mind for it, then. If I say I want thumbnails to be
200px wide, then I don't want some editor at the other end deciding I need it
scaled up 200%.

A reasonable point, but one that would suggest we should eliminate *all* pixel
sizing for thumbnails. If absolute scaling is bad, surely relative scaling is
better.

robchur wrote:

This bug still has the practical problems that bug 495 did, i.e. caching and
rendering and all sorts of fun things with variables per image, but brush those
aside...I still can't understand why the scenario above warrants special
treatment of this nature.

If I insert "[[Image:Foo.png|thumb|left]]" into a page, I'm saying, "insert
Foo.png into the document at this point, use the viewer's thumbnail preference
to scale it, and float it to the left." The viewer can negotiate to see that
image scaled to one of the widths as mentioned above. Everything's hunky dory.

If I decide, in my infinite editorial wisdom, that Foo.png is of pressing
importance to the reader, then I might use "[[Image:Foo.png|500px|left]]" to
ensure it's scaled right up, and emphasise it.

Your request as I understand it is asking for me to able to use
"[[Image:Foo.png|200%|left]]", causing the image to be scaled up to 200% of
whatever the user's thumbnail preference is, and I can see problems with it.
Let's suppose the preference is 500px; we've got a thousand pixel wide image
which the user didn't expect to see. You have no idea that it's going to be
1000px wide, however; your editorial control is gone, and so is their viewing
control.

I concede that this *could* be useful in some, small, isolated cases. It just
doesn't sound quite right, to me.

ayg wrote:

(In reply to comment #6)

If I decide, in my infinite editorial wisdom, that Foo.png is of pressing
importance to the reader, then I might use "[[Image:Foo.png|500px|left]]" to
ensure it's scaled right up, and emphasise it.

The problem is that if the viewer's setting is already 500px by default, because
he's using a huge plasma screen or something, he won't notice a difference. If
it's 120px, because the viewer is using a cell phone or PDA, then the image
would be ridiculously large, possibly taking up the entire width of the screen.
If a thumbnail needs to be emphasized, it has to be emphasized relative to the
default, or else it won't work as intended for people who don't use the default.

z9z8z-wps wrote:

(In reply to comment #6)

Your request as I understand it is asking for me to able to use
"[[Image:Foo.png|200%|left]]", causing the image to be scaled up to 200% of
whatever the user's thumbnail preference is, and I can see problems with it.
Let's suppose the preference is 500px; we've got a thousand pixel wide image
which the user didn't expect to see. You have no idea that it's going to be
1000px wide, however; your editorial control is gone, and so is their viewing
control.

A reasonable user with a small display would probably not set it that high (and the max is 300px anyway). But consider people with a large
display, visually impaired or whoever who might have a good reason to have pictures or a whole page enlarged. Those expect to see the
sizes of all thumbs on a page in their correct (by the author intended) relation to each other if they change that preference size. Changing
the browser's enlargement does only affect the fonts not the pictures.

On the other end there are browsers for mobile devices like PDAs or cell phones. These might be able scale pictures automatically, but it
could be necessary to adjust the sizes further.

If it makes it easier, think of XS, S, M, L, and XL sizes in the preferences and that the user wants the software to do things just as he expects
to.

mvdRoehe wrote:

What "Changing the browser's enlargement does" depends on the type of enlargement, and
the Browsers capabilities. Choose Opera, and you have both character-only and all-
there-is-shown-(images-included) types of enlargements at hand. I must apologize for
advertizing a specific product. May be others have these features, too.

j.anvier wrote:

I would like to add my support for this because most browsers do not do this and
it would be really useful. Plus it is right in the spirit of HTML. For text, you
can select a text size (h1, h2...) and the user can alter the size by selecting
a scale factor that preserves the relative size (h1 becomes like h2 and so on,
for example). It should work the same for images to keep a good layout. Image
size are meaningful to.

In most case, all size are precised relatively to others images and text, not
because of an absolute size requirement.
You may want to set a size for an image because it is much taller than large but
that does not mean you want it at a specific size; you just want to avoid it to
be so much tall compared to others. Or because an image is more important than
another and need some emphasis. Again, no reason to set at a specific size, the
ratio only is important.

Actually, I can't see any reason to set a fixed size for a thumbnail (or maybe
to avoid some over-resampling?). As a graphics programmer, I work with a wide
variety of resolutions from 1024x768 to 1920x so trust me when I say it would be
just great; someone setting 500px to put emphasis is just covering 1/4 of my
precise screen width (which not big really)...

Actually, if you look at Firefox, you'll see it has two settings and this
solution is great I think: one is a text magnification factor, the other one is
a minimal text size. With this ou can do your best for small and big devices.
Would be great if Wikipedia didn't have to rely on a potential browser support
for these kind of features, being text (css does it already) or images.

Also, note that it does not need to be a very precise resizing. You can just
fallback to the neareast size available on the server.

ayg wrote:

(In reply to comment #10)

Actually, I can't see any reason to set a fixed size for a thumbnail (or maybe
to avoid some over-resampling?). As a graphics programmer, I work with a wide
variety of resolutions from 1024x768 to 1920x so trust me when I say it would be
just great

Browser resizing tends to be poor-quality. Forcing resizes to be server-side
allows us to have images that don't appear to some percentage of our users as
though they were resized in MS Paint.

addicks wrote:

Recalculating all these thumbnail-sizes based on the usersetting would generate -as i
understand- much load for the imageservers.

For me it would be sufficient, if not %-values for the size were allowed but something like

• |thumb|half|,
• |thumb|oneandhalf|
• |thumb|double|
• |thumb|triple|

otherwise you can declare "only values of 50pc, 150pc, 200pc and 300pc are valid"

This would drastically reduce the number of neccesary prescaled thumbs.

z9z8z-wps wrote:

(In reply to comment #12)

This would drastically reduce the number of neccesary prescaled thumbs.

A thumb of size 120 % would need to be calculated just as often as a thumb of size 100 %. So it would only make a difference if the same
picture is used multiple times with different thumb sizes, which as I think won't happen frequently.

ayg wrote:

(In reply to comment #12)

Recalculating all these thumbnail-sizes based on the usersetting would

generate -as i

understand- much load for the imageservers.

Are non-standard user thumbnail sizes even cached at all? Most things aren't
for users, because the overwhelming majority of WMF hits are anons and
accounting for all the different option permutations will generally end up being
a total waste of resources.

• Bug 8682 has been marked as a duplicate of this bug. ***

Oops, I haven't seen this bug before, but I think with the introduction of parameter "upright" and "upright=factor" - r22305 - this bug can be closed as fixed.

Syntax:

• [[Image:Name.jpg|thumb|upright|right|text]] particularly for upright images, the width/height will be scaled down by the factor 0.75 related to the standard width (180px for anons) or the thumb width from user preferences.

• [[Image:Name.jpg|thumb|upright=0.5|right|text]] the image will be scaled down by the given factor (here: 0.5) related to the standard width (180px for anons) or the thumb width from user preferences.

For cache healthy the scaled width will be rounded to xx0 px.

I really don't like 'upright' or 'upright-factor' at all, and would recommend taking them right back out. It would make more sense for the standard thumbnail size to be a box size with an appropriate height.

wikipara wrote:

Can the 'upright' parameter be renamed or aliased to 'scale' or 'downscale'?

Having the scale word in the parameter name would imply its direct effect, and not just mark the image as portrait form with the downscaling side effect (why 0.75?), which could be done automatically anyway if it really was wanted. Scaling an image of a possibly changing aspect ratio down by an editor chosen percentage isn't much better than scaling it to an editor preferred pixel size.

The correct solution for whatever problem 'upright' is trying to solve, would indeed be to make the default thumbnail size a box size instead.

Tables and columns can be set in a variety of units: pixels, ems, points, %. There is a consensus that pixels are the very worst choice of units for accessability reasons. The same arguments just have to apply to images, probably even more so.

(In reply to Brion Vibber from comment #17)

I really don't like 'upright' or 'upright-factor' at all, and would
recommend taking them right back out. It would make more sense for the
standard thumbnail size to be a box size with an appropriate height.

Bug 63903, asking the px limit of thumbs to apply to both sides, was rejected.
https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes currently proposes bug 63904 which would do that for 'upright'.

This bug however doesn't seem to be about width vs. height vs. both, it's about making thumb size relative to user preferences: correct? Changing summary.

(In reply to Brion Vibber from comment #17)

I really don't like 'upright' or 'upright-factor' at all, and would
recommend taking them right back out. It would make more sense for the
standard thumbnail size to be a box size with an appropriate height.

No, please don't do that. The upright parameter is used for tall images. These often look badly oversized at the standard width. The upright parameter usually fixes it without any values entered (just the default) and if it doesn't editors can adjust using editorial judgement. Without it we would be back to using pixel values which will do a disservice to all users who do not have exactly the same size screen as the editor who entered the pixel value.

Whether you guys like it or not, upright exists and can be used to do what the original reporter asked for.

[[File:Preveli Palm Beach Panorama 02.JPG|thumb]]
[[File:Preveli Palm Beach Panorama 02.JPG|thumb|upright=0.5]]