Revert image crop for now:
authorBrion Vibber <brion@users.mediawiki.org>
Wed, 19 Aug 2009 02:07:00 +0000 (02:07 +0000)
committerBrion Vibber <brion@users.mediawiki.org>
Wed, 19 Aug 2009 02:07:00 +0000 (02:07 +0000)
commit787ff66c852c746ea87f10910279a51cc4a765dd
tree3bcdf88a006bf3cb19a8257ed85156e0e2d9f4c4
parent4684e284e0d5d4a6912835833986876dc996d21d
Revert image crop for now:
r54746 "Update formatting for r54745"
r54745 "Added crop support for inline images."
r54748 "Making demon happy (adding public/protected to function definitions) and add some comments along the way."

Several issues:
* Implementation is ImageMagick-specific, no support for GD backend
* Specification syntax is pretty ugly and non-obvious imo... [[File:foo.jpg|<width>px|<left>x<top>x<width>x<height]]
* Crop syntax seems to be tied to pixels... I _presume_ source pixels? This would break if a file is re-uploaded with a new size.
* In general I'm very leery of tacking on more infinite-options-in-infinte-combinations for image rendering; our treatment of resizing already has implications for CPU and disk usage and this just adds another level of arbitrary-rendered horror. ;)

I'd much rather we move towards limiting the number of rendered variants we have, not increase them... IMO cropping would be better served with an interface allowing for explicit, visible cropping which creates either a new saved version, or a 'cloned' virtual file which can be referred to by name... and more importantly, uses of it would be trackable so that if crops needs to be updated they can be cleanly.
RELEASE-NOTES
includes/media/Bitmap.php
languages/messages/MessagesEn.php