[drupal-devel] New image.module

[Stefan Nagtegaal]

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