Last modified: 2014-06-05 08:47:13 UTC
There should be an option to display Images as square thumbs. [[File:Foo.jpg|square-150px|caption]] http://www.imagemagick.org/Usage/thumbnails/#cut
As always, it would be good to include your intended use case for such a feature.
I want to (automatically) create small preview icons for featured and new articles articles on Main Page and maybe on Special:Search as well. They should have the same size, not like image results on Special:Search (or Facebook website link posts) where tall and wide images are badly displayed on small thumb size.
Edit: Facebook does square thumbs as well now in the timeline
Using a template now with a combination of http://www.mediawiki.org/wiki/Extension:ImageSizeInfoFunctions and div background-images but real square thumbs would be proper.
(In reply to comment #4) > Using a template now with a combination of > http://www.mediawiki.org/wiki/Extension:ImageSizeInfoFunctions and div > background-images but real square thumbs would be proper. Agreed, real parameter is better. Doing this with css in that manner would be a disgusting hack ;)
Not really disgusting ;) http://www.mixesdb.com/w/Template:SquareThumb
This would involve adding a new namespace for these square cropped images, distinct from the width-based filenames currently used for thumbanils. If someone tackled this task, fixing bug 24763 might also be a good idea to do at the same time, since it also requires a new filename namespace.
I don't see why this would require a new namespace. Why can't additional thumbs be created if requested? E.g."150px-square-[focus]-Filename.jpg" while [focus] can be left/center/right or top/middle/bottom.
I propose: [[File::Filename.jpg|crop|100x200px]] which would return an image *exactly* 100x200px, cropped as necessary. As an elaboration, you might allow crop=[focus] as comment 8 suggests. The files would be named (for swift and the image scalers) as: crop-[focus]-100x200px-Filename.jpg
I feel like the people in wmf projects would not use this feature (thats unsubstiatiated though). I would be opposed to making core thumbnailing more complicated then it is unless a large number were prepared to use the feature. Maybe this would be more appropriate as an extension, although not exactly an easy thing to "extend"
@bawolff: As @Waldir links, there are a number of existing bugs/feature requests which this could address. Cropped thumbnails of a consistent size look better in galleries (bug 65451) including implicit category-based galleries (bug 13802). They also look better in printed output, and designers like them in general for their consistency. Obviously you wouldn't want to use cropping for diagrams or similar images, but most photo-style images can benefit.
(In reply to C. Scott Ananian from comment #11) > @bawolff: As @Waldir links, there are a number of existing bugs/feature > requests which this could address. Cropped thumbnails of a consistent size > look better in galleries (bug 65451) including implicit category-based > galleries (bug 13802). They also look better in printed output, and > designers like them in general for their consistency. Obviously you > wouldn't want to use cropping for diagrams or similar images, but most > photo-style images can benefit. Last time I mentioned something like this to people at commons, response was pretty negative (A whole lot of "this aint facebook" and "its important to show the full context of the image type of responses" [To be honest, I have no idea how facebook played into it, that's just what I remember people saying]). Anyways, I'd suggest bringing it up with users before anyone tries to implement any of this.
Also related is bug 7757, which offers a different cropping mechanism (and use cases). To satisfy all the use cases in bug 7757, you would need to specify an exact "center" of the crop as well as a scale factor. Something like: [[File:Filename.jpg|crop=50x50|scale=2|100x200px]] (In bug 63904 it is proposed to add 'scale' as a synonym for 'upright'.)
