Last modified: 2014-06-12 20:59:58 UTC
Users are allowed to change the default size of 180 pixels for picture thumbs in their preferences. MediaWiki should allow percentage values for the thumb size in the [[Image:...|thumb|...]] syntax instead of pixel sizes only. This would allow to honor the user's settings for differing thumb sizes by scaling them appropriately and make the display of thumbs independent from the actual resolution of the output device. It should be possible to give percentage values relative to - the default size (or preference setting). This would be for normal thumbs. - the current display width. For example to scale a panoramic picture with a large aspect ratio to display width.
*** This bug has been marked as a duplicate of 495 ***
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.)
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%.
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.
(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.
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.
(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.
(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.
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.
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.
(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.
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.
(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.
(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.
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.
