[drupal-devel] New image.module

James Walker walkah at walkah.net
Mon Feb 28 00:04:52 UTC 2005

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 

> 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 


More information about the drupal-devel mailing list