James Walker schreef:
On 27-Feb-05, at 7:28 AM, Stefan Nagtegaal wrote:
After having studied more and more of the new image(-api|.module), i have some concerns, which are: - We currently assume that everybody has at least GD 2.0, which is a bad thing imo. Imo we should move the GD 2.0 functions like image_gd_(settings|resize|rotate|crop|open|close) into a separate image.gd2.inc and make a image.gd1.inc file. just like we did for the ImageMagick, which currently lives in silence under Walkah's Sandbox...
We don't actually make any assumptions about GD version. If you'll notice all of the "gd2-only" functions are wrapped by 'function_exists' calls, and fall back on the gd1 versions if not defined. I'm pretty sure this fails gracefully... If you're seeing a *specific* issue with handling under gd1 handling, then I'd be more than happy to patch it. We do however, only include gd* by default (as gd2 is bundled with recent php). imagemagick, etc will be available as well as an extra download.
Well, I have 2 hosts currently.. I tried to run the image.module with a standard image.inc on a host with GD 1.6.2 (http://frontaal-online.com/phpinfo.php) where it is failing to work.. It looks like the function imageCreateTrueColor is known, but is not present nor working.. So, it fails to work.. I still would like to see the image.module split into 3 files. - image.inc - image.gd1.inc & - image.gd2.inc. then we can leave the image.inc in core, so the api is present. But whenever people would like to have image manipulation capabilities, they downoad the image.$toolkit.inc file which matches their needs.
I thought a little more about the fact how we should be able to override the standard way how thumbnails/photo's are generated. (Think about how to accomplish something like this: http://frontaal-online.com/fotoalbum/oude-doos).
In my opinion this _really_ is a theme issue, so it would be nicef there could be a way how we can deal with this in that place.. But, I'm sure that this needs more thought.. In the meanwhile everybody is free to rewrite and modify a image.$name.inc file which does exactly what you want.. Still, I think that's not quite optimal...
I am looking forward to your answers and opinions about this...
I don't agree. I think alternate 'derivative' generation is better. the main issue is providing hooks that make sense, are easy to use without creating nasty conflicts (i.e. what if 2 modules are installed that try to generate varied thumbnails?). But i think it's better to solve those issues, rather than throwing a bunch of code and processing into themes.
-j
I think - looking from your point of view - i do agree with you guys.. Probably, pepole could rewrite the image.$toolkit.inc file for specific needs or advanced image manipulation. Which I did currently at 3 different hosts, and it works awesome! :-) Stefan