Everything

php

gd development as part of php.net

php.internals

Thomas Boutell

20 years ago

Unfortunately there hasn't been any movement on this since I handed
it over to Pierre in April.

Obviously, since I sat on PHP myself for a really long time, I am not
pointing the finger at Pierre here. I'm still the champion
gd-neglect-ster by a LONG shot.

However, I'm wondering if anyone else is eager to help him make a
new release of gd happen as part of the PHP project.

If necessary, I could go looking for a new maintainer again, though
that surely wouldn't be fun and I'd prefer almost anything else. (:

* * *

On a related note, I'm wondering why PHP doesn't seem to have any
official relationship with the ImageMagick project - Which offers
an unofficial PHP extension of its own.

Though gd has been good to me over the years, I'm not going to sit
here and pretend gd has a modern graphics API. It doesn't. gd has a
very 1989 API, full of integer-oriented assumptions and
less-than-smooth implementations of graphics primitives, written
by a guy with no formal background in graphics algorithms (me).
And that's always going to be visible in the quality of its output,
short of a total core rewrite and API redesign.

The good thing about gd was always the simple API - but a simple
API at the C level doesn't necessarily help anymore when the
end user isn't coding in C anyway. And ImageMagick has a
floating-point, vector-oriented API that can do a whole lot more.
With a coder-friendly "MagickWand" API that gives it simplicity
approaching gd, especially when used from languages like PHP.

Also, the ImageMagick license appears to be GPL-compatible
and making-money-compatible:

http://www.imagemagick.org/script/license.php

So, at the expense of my own site traffic perhaps, why the outdated
gd API and not ImageMagick in the official PHP builds?

--
Thomas Boutell
Boutell.Com, Inc.
http://www.boutell.com/

Olivier Hill

20 years ago

On 8/30/06, Thomas Boutell <boutell@boutell.com> wrote:

> Unfortunately there hasn't been any movement on this since I handed
> it over to Pierre in April.
>
> Obviously, since I sat on PHP myself for a really long time, I am not
> pointing the finger at Pierre here. I'm still the champion
> gd-neglect-ster by a LONG shot.
>
> However, I'm wondering if anyone else is eager to help him make a
> new release of gd happen as part of the PHP project.

Hello Thomas,

I surely can help Pierre with this. I don't know how much time I can
give it to the project, but since I'm using more and more the GD API
to do tons of stuff in PHP and I'm seldomly finding limitations, it
can perhaps be a good thing for me to jump into the code.

I'll read more about the implementation in PHP and contact Pierre if I
can do something.

Sincerely,
Olivier

Pierre Joye

20 years ago

Hello,

On 8/31/06, Thomas Boutell <boutell@boutell.com> wrote:

> Unfortunately there hasn't been any movement on this since I handed
> it over to Pierre in April.

I'm not sure what you consider as movement. There is many things
achieved since april. Security fixes has been reported to the various
distributions with patches and solutions.

Yes, a 2.0.34 is now due as all distros have the security fixes
included, php with the fixes have released. However, please consider
what is to do prior to a release, regarding the configuration
management, the tests and some minimum QA.

I was waiting years to get move in this library,  I am very happy that
you finally agreed on them (like having the cvs), now I make sure that
the future of its development can be as good as possible, in the best
conditions. That's not a small job.

Thanks for your understanding.

Regards,
--Pierre

Jared Williams

20 years ago

> -----Original Message-----
> From: Thomas Boutell [mailto:boutell@boutell.com]
> Sent: 31 August 2006 00:17
> To: internals@lists.php.net
> Subject: [PHP-DEV] gd development as part of php.net
>
> Unfortunately there hasn't been any movement on this since I handed
> it over to Pierre in April.
>
> Obviously, since I sat on PHP myself for a really long time, I am not
> pointing the finger at Pierre here. I'm still the champion
> gd-neglect-ster by a LONG shot.
>
> However, I'm wondering if anyone else is eager to help him make a
> new release of gd happen as part of the PHP project.
>
> If necessary, I could go looking for a new maintainer again, though
> that surely wouldn't be fun and I'd prefer almost anything else. (:
>
> * * *
>
> On a related note, I'm wondering why PHP doesn't seem to have any
> official relationship with the ImageMagick project - Which offers
> an unofficial PHP extension of its own.
>
> Though gd has been good to me over the years, I'm not going to sit
> here and pretend gd has a modern graphics API. It doesn't. gd has a
> very 1989 API, full of integer-oriented assumptions and
> less-than-smooth implementations of graphics primitives, written
> by a guy with no formal background in graphics algorithms (me).
> And that's always going to be visible in the quality of its output,
> short of a total core rewrite and API redesign.
>
> The good thing about gd was always the simple API - but a simple
> API at the C level doesn't necessarily help anymore when the
> end user isn't coding in C anyway. And ImageMagick has a
> floating-point, vector-oriented API that can do a whole lot more.
> With a coder-friendly "MagickWand" API that gives it simplicity
> approaching gd, especially when used from languages like PHP.
>
> Also, the ImageMagick license appears to be GPL-compatible
> and making-money-compatible:
>
> http://www.imagemagick.org/script/license.php
>
> So, at the expense of my own site traffic perhaps, why the outdated
> gd API and not ImageMagick in the official PHP builds?

There is a magickwand extension for PHP.
http://www.magickwand.org/download/php/
I was involved in getting the windows builds of it made, until the lead
familiarised himself with Win32/VC.

The intention was to get it on pecl at some point.

But the lead developer has, to my understanding, been too busy.

Its quite a massive API. I think there are ~477 functions wrapped an available
to be used in PHP. Which obviously is going to create huge load on
documentation/bugs etc.

Jared