Last modified: 2014-04-14 14:45:06 UTC
one cannot display on wikipedia a thumbnail of File:George-W-Bush.jpeg at a height of exactly 600px. one can attempt to constrain it by height and no width (enter [[File:George-W-Bush.jpeg|x600px]]). however this produces a 453 × 599 image (!) while the next available size 454 × 601. suppose a user needs to arrange horizontally several photos of arbitrary dimension while keeping their top and bottom edges aligned. in many cases this requires working backwards by coin-shaving the original images in a graphics editor until round( $srcHeight * $dstWidth / $srcWidth ) happens to equal the desired height. for narrower aspect ratios (flag-poles, longcat, yao ming) this issue will be more certain to arise. the most obvious solution is to pass the size parameter directly to image- magick as widthlessly (breadthlessly?) specified, e.g. this serves me well for a local copy of the same photograph; the height is not replaced by a dependent round-trip calculation. owner@lappy:~$ convert George-W-Bush.jpeg -thumbnail x600 w.jpg owner@lappy:~$ identify w.jpg w.jpg JPEG 453x600 453x600+0+0 8-bit DirectClass 86.2KiB 0.000u 0:00.000 since mediawiki isn't doing it this way already, i should guess the real issue lies in gracefully adopting a new thumbnail url pattern (one which incorporates the height-dimension in some fashion), or no?
Is this a duplicate of bug 25989?
This bug is actually very annoying not only because it can't create thumbnail with exact height, but also because it will make the image VERY BLURRY. The way currently mediawiki doing is to create a 453 × 599 image and then set it height to 600px by html code, which will made the image very blurry. Example: https://en.wikipedia.org/wiki/User:%E7%83%88%E4%B9%8B%E6%96%A9/sandbox HTML code: <img style="width: 117px; height: 190px;" alt="Tim Conway cropped.jpg" src="//upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/117px-Tim_Conway_cropped.jpg" class="thumbborder" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/176px-Tim_Conway_cropped.jpg 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/4/40/Tim_Conway_cropped.jpg/234px-Tim_Conway_cropped.jpg 2x" height="190" width="117">
Hm. This behavior is pretty fundamental to the way mediawiki handles scaling. It names thumbnails using only the width. it can't distinguish between the 453x599px image caused by requesting "width=453px" and the 453x600px image which you want to result from "height=600px". They would both have the same filename: 453px-Foobar.jpg". I don't think this bug is related to bug 25989 at all, nor is it strictly related to the square bounding box RFC. Fixing the issue would require (at least) adding the height to the thumbnail filename. You'd also have to worry about the storage issues involved with storing (for example) both a 453x599 and a 453x600 version of the same image. One current proposal is to drastically limit the number of 'standard' thumbnail sizes (https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes). I do agree that it would be best if "square bounding boxes" (https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes) actually resulted in exactly the requested height, as this bug requests. But neither issue strictly depends on the other.
