Re: Re: ext/imagick BC break (was: Re: [PEAR-DEV] PHP Magick version 0.5a Released!)
| From: | Michael Montero | Date: | Tue, 26 Nov 2002 15:40:23 +0000 |
| Subject: | Re: Re: ext/imagick BC break (was: Re: [PEAR-DEV] PHP Magick version 0.5a Released!) | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-11112@lists.php.net to get a copy of this message | ||
Quite frankly, no haven't considered it.
On Tue, 26 Nov 2002, George Schlossnagle wrote:
> Since you're breaking BC, have you considered making the new imagick
> interface OO? There is enormous bloat in the php global function table,
> keepinf all your method names in a private namespace would be nice.
>
> George
>
> Michael Montero wrote:
>
> >Quick review, I will work on the doc. and forward around. Will shoot for
> >today (althought most of the doc. is already below). These functions are
> >supported:
> >
> >PHP_FUNCTION(imagick_border);
> >PHP_FUNCTION(imagick_frame);
> >PHP_FUNCTION(imagick_resize);
> >PHP_FUNCTION(imagick_sample);
> >PHP_FUNCTION(imagick_crop);
> >PHP_FUNCTION(imagick_rotate);
> >PHP_FUNCTION(imagick_shear);
> >PHP_FUNCTION(imagick_oilpaint);
> >PHP_FUNCTION(imagick_annotate);
> >PHP_FUNCTION(imagick_convert);
> >
> >I haven't looked at each specifically but there is a chance the parameter
> >order changed. UNLESS (and I believe Christian and I followed this
> >standard) the handle is the first parameter and the subsequent parameters
> >match the order in which they are passed to the ImageMagick functions. I
> >looked at imagick_resize (old one) and the new one and they are dead on.
> >
> >These functions have been made backward compatible:
> >
> > PHP_FUNCTION( imagick_read ) ; /* => imagick_readimage() */
> > PHP_FUNCTION( imagick_write ) ; /* => imagick_writeimage() */
> > PHP_FUNCTION( imagick_free ) ; /* => imagick_destroyhandle() */
> >
> >These have been deprecated:
> >
> > PHP_FUNCTION( imagick_add_resource ) ;
> > PHP_FUNCTION( imagick_list_magickinfo ) ;
> > PHP_FUNCTION( imagick_new ) ;
> > PHP_FUNCTION( imagick_init ) ;
> > PHP_FUNCTION( imagick_copy_sample ) ;
> > PHP_FUNCTION( imagick_copy_resize ) ;
> > PHP_FUNCTION( imagick_copy_crop ) ;
> > PHP_FUNCTION( imagick_copy_shear ) ;
> > PHP_FUNCTION( imagick_copy_rotate ) ;
> > PHP_FUNCTION( imagick_copy_morph ) ;
> > PHP_FUNCTION( imagick_dump ) ;
> >
> >A few explanations:
> >
> >imagick_add_resource() and imagick_list_magickinfo() aren't entirely
> >necessary anymore. The phpinfo() will list everything that
> >imagick_list_magickinfo() would dump to a file. If anyone disagrees, I
> >can implement the function but I'd rather the data in phpinfo() then
> >requesting PHP to dump a file. imagick_add_resource() will be supported
> >in SOME fashion with regard to image lists. I believe this will use the
> >ImageMagick push functions and should appear perhaps today. If I CAN make
> >this function backwards compatible I will.
> >
> >imagick_new() has no meaning...to create a new handle you either have to
> >create a canvas or read an image. Currently you can read an image from a
> >file and by the time we're done from a blob of data as well. You can
> >create a canvas of a specified size and color. Coming soon will be
> >creating a canvas with a tiled background created from a custom image.
> >
> >imagick_init() isn't necessary anymore. ImageMagick needs to be
> >initialized but I have removed the need for the user to remember doing
> >this. The module will initialize itself and clean up after itself.
> >
> >imagick_copy* functions are too ambitious. The ImageMagick library is
> >enormous and writing a corresponding copy function for every operation, in
> >my opinion, is a wasted efforted (again, based solely on the number of
> >functions available in ImageMagick). Instead, I support this:
> >
> ><?
> > $existing_handle = imagick_readimage( "./image.jpg" ) ;
> > $new_handle = imagick_clonehandle( $existing_handle ) ;
> >
> > // now execute a function on the cloned handled
> >?>
> >
> >In other words, instead of the function creating a new handle and
> >returning it to you, you'd create a new handle and operate on it.
> >
> >imagick_dump(): I thought about this a lot. This essentially writes the
> >image file out, then reads it and writes it to the browser. This seems
> >like a lot of effort if all the user wants to do is work on an image and then
> >just display it. You can achieve this with the new API by doing:
> >
> ><?
> > $handle = imagick_readimage( "./image.jpg" ) ;
> >
> > header( "Content-type: " . imagick_getmimetype( $handle ) ) ;
> > print $image_data = imagick_image2blob( $handle ) ;
> >?>
> >
> >If you want to write the file you can do so at another point or not do it
> >at all.
> >
> >If anyone disagrees with this assessment let me know. I can put some work
> >into some of it. However, I'm pretty opposed to the copy functions.
> >There would need to be something like 20 or 30 (perhaps more) in addition
> >to the same functions that operate on image itself without copying it. This
> >seems like far too much to support. It makes more sense to me to let the
> >user clone the handle when that's what they want and start operating on a
> >different image entirely.
> >
> >Let me know what you think.
> >
> >On Tue, 26 Nov 2002, Alan Knowles wrote:
> >
> >>Michael Montero wrote:
> >>
> >>>I will clearly document how to go from the BC version to the new one.
> >>>
> >>can you give a 2-3 line overview of the differences:
> >>functions have different arguments/order?
> >>missing functions?
> >>(lots of new ones I presume :) ...
> >>
> >>phpmole uses it to do resize/rotate etc.
> >>Regards
> >>Alan
> >>
> >>
> >>>
> >>>
> >>>On Mon, 25 Nov 2002, Christian Stocker wrote:
> >>>
> >>>
> >>>
> >>>>Hi
> >>>>
> >>>>As mentioned in the mail by Michael, we will replace pecl/imagick with his
> >>>>version, as I think, he has much more to offer than my code (and much more
> >>>>time to support it right at the moment :) ). I will still support the
> >>>>extension and hopefully contribute to it.
> >>>>
> >>>>Therefore here comes the big WARNING:
> >>>>
> >>>>The commits (and finally releases) in the next few days will break BC of
> >>>>pecl/imagick! Therefore, if anyone is using this extension and really
> >>>>really needs BC should stand up now and maybe we will have a look what we
> >>>>can do :) But since it's clearly stated as alpha and experimental, noone
> >>>>should be surprised by that
> >>>>
> >>>>Anyway, have a nice evening and check out Michael's work.
> >>>>
> >>>>christian
> >>>>
> >>>>
> >>>>
> >>>>On Mon, 25 Nov 2002, Michael Montero wrote:
> >>>>
> >>>>
> >>>>
> >>>>>Just released some more functionality. The major push right now is join
> >>>>>my efforts with those of Christian Stocker to get one single module into
> >>>>>PEAR. Christian and I have been working that. Please see the latest
> >>>>>changes below...they are significant.
> >>>>>
> >>>>> - functions added:
> >>>>> imagick_getcanvas()
> >>>>> imagick_blur()
> >>>>> imagick_despeckle()
> >>>>> imagick_edge()
> >>>>> imagick_emboss()
> >>>>> imagick_enhance()
> >>>>> imagick_gaussianblur()
> >>>>> imagick_medianfilter()
> >>>>> imagick_motionblur()
> >>>>> - one major change - renamed everything to imagick*; I've
> >>>>> joined
> >>>>> my efforts with Christian Stocker who had a previously written
> >>>>> but smaller extension
> >>>>> - magick_getcanvas() allows you to create a blank image to draw on
> >>>>> - changed comment header in imagick.h to match the one in
> >>>>> imagick.c
> >>>>> - added Christian Stocker to credits
> >>>>> - moved over to Christian Stocker's config.m4, removed the need
> >>>>> for gen_configm4
> >>>>> - rewrote INSTALL to reflect new config.m4
> >>>>> - slight modifications to config.m4 to get it to work properly
> >>>>> - added package.xml
> >>>>> - removed ChangeLog, everything is now in package.xml
> >>>>> - removed imagick_free_reason() and imagick_free_description()
> >>>>> since they are no longer necessary
> >>>>> - preceded all internal functions with _php_
> >>>>> - created imagick_read() for backward compatibility with old
> >>>>> extension
> >>>>> - created imagick_write() for backward compatibility with old
> >>>>> extension
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
>
>
--
Michael C. Montero
Chief Technology Officer
Community Connect Inc. Co-founder
MMontero@Mail.CommunityConnect.com
-=-=-=-=-= Community Connect Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The Premier Source of Interactive Online Communities 149 Fifth Avenue
http://www.CommunityConnectInc.com/
New York, NY 10010
http://www.AsianAvenue.com/ http://www.BlackPlanet.com/
Click into Asian America The World Is Yours
http://www.MiGente.com/ http://www.DiversityJobMarket.com/
The Power of Latinos In partnership with The New
York Times
----- Your Message May Appear Below This Line