[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
download.
> 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
More information about the drupal-devel
mailing list