Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75992
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F87DEB6A-3F42-4903-9D93-3CF4126897AB@lonnylot.com>
References: <F87DEB6A-3F42-4903-9D93-3CF4126897AB@lonnylot.com>
Date: Thu, 24 Jul 2014 09:13:29 +0200
Message-ID: <CAEZPtU7D7wPavvJm3V302C7E5OX+s1AP26QVuHE86i8m757X7Q@mail.gmail.com>
To: Lonny Kapelushnik <lonny@lonnylot.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: Deprecating GD functions imagettftext/bbox
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Tue, Jul 22, 2014 at 9:01 PM, Lonny Kapelushnik <lonny@lonnylot.com> wro=
te:
> Morning,
>
> I propose deprecating two GD functions: imagettftext and imagettfbbox.
>
> The reasons I would like to deprecate them are:
> 1. Their functionality is a subset of imagefttext and imageftbbox
> 2. The imagettf* functions have the same requirements as the imageft*
> functions
> 3. The imagettf* functions parameters are compatible with the imageft*
> functions parameters
>
> As far as I can tell the original reason for having both functions was
> because PHP LIBGD is a custom implementation of LIBGD that had additional
> functionality from the actual LIBGD. While this is still the case it seem=
s
> that now the required functions (gdImageStringFT and gdImageStringFTEx)
> exist in both libraries.
>
> The only difference between imagettf* and imageft* functions is the
> imagettf* functions do not provide the optional =E2=80=98extrainfo=E2=80=
=99 parameter
>
> The only step to migrate from the imagettf* functions to imageft* functio=
ns
> is to change the function names from =E2=80=98imagettf*=E2=80=99 to =E2=
=80=98imageft*'
>
> I would like to create a timeline to deprecate and remove the imagettf*
> functions. Providing a timeline will allow for:
> 1. Clarity for which PHP functions to use going forward
> 2. Ability to plan a migration to the new PHP functions
> 3. Clarity for which PHP functions to improve in php-src
> 4. Ability to clean up some of the GD code in php-src
>
> I will hold off on proposing an actual timeline for now.
>
> I can implement any coding changes needed.
>
> Please let me know the general thoughts to deprecating these functions. I=
f
> the reception is positive I would like to  create an RFC to discuss this =
in
> full and come up with a timeline.

It is on my list to mark them as deprecated in the documentation. Also
I am not sure it is worth the disagreement for the users to add
notices or even to remove them as they both use the same underlying
code. Basically there is no gain for us to actually remove them but
yet another notice for the users.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org