Bug #47757 [Com]: JPG vs JPEG
Edit report at http://bugs.php.net/bug.php?id=47757&edit=1 ID: 47757 Comment by: test at test dot com Reported by:frank at scriptzone dot nl Summary:JPG vs JPEG Status: Closed Type: Bug Package:GD related Operating System: Any PHP Version:5.2.9 Assigned To:pajoye Block user comment: N Private report: N New Comment: So unfortunately this fix had a side effect of breaking various scripts that checked for JPEG image format support in GD by calling gd_info() and looking for the key 'JPG Support' . I'm surprised that the source of this breakage was just this complaint about compiler flag labeling. Support for existing runtime behavior and avoiding breaking currently working scripts should easily trump worries about compiler flag consistency, it would be cool to take that more into account in the future. Previous Comments: [2009-03-24 09:46:02] paj...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. [2009-03-24 09:35:19] frank at scriptzone dot nl Description: I think inconsistent naming is quite annoying. To compile GD with JPEG support you have to do something like ./configure --with-gd --with-jpeg-dir. However in phpinfo pages JPEG support is displayed as "JPG Support enabled". So basicly, when I actually successfully compiled GD with JPEG-support: I thought it failed because I was looking for "JPEG" in phpinfo, and not "JPG". Not quite an essential bug, but perhaps worth fixing in the future. Reproduce code: --- './configure' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with-ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '--enable-exif' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' '--with-mysqli=/usr/local/mysql/bin/mysql_config' '--with-mysql=/usr/local/mysql' '--with-openssl' '--with-xmlrpc' '--with-xsl=/usr' '--without-pear' --with-jpeg-dir=/usr/local/lib/ --with-gd Expected result: JPEG support Actual result: -- JPG support -- Edit this bug report at http://bugs.php.net/bug.php?id=47757&edit=1
#32921 [Com]: ImageRotate() lost of alphalayer
ID: 32921 Comment by: test at test dot com Reported By: eckounlimited at gmx dot nnet Status: No Feedback Bug Type: GD related Operating System: * PHP Version: 5CVS-2005-05-02 (dev) Assigned To: pajoye New Comment: consider this as a bug or just gd's weaknessess: - imagerotate is not alpha-able - any animation picture (gif) is not properly rotated and not alpha-able too need to upgrade this function Previous Comments: [2005-05-14 01:00:04] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-05-06 18:56:03] [EMAIL PROTECTED] Hi, Partially fixed in CVS, will commit asap the definitive fix, keeping BC. --Pierre [2005-05-06 03:17:40] [EMAIL PROTECTED] Are you using bundled gd library or external one? (what do you pass to --with-gd configure option?) [2005-05-03 08:44:10] eckounlimited at gmx dot nnet Description: Imagerotate between -45 an 45 degree including an alphachannel is no problem! 46 to -44 ist still replacing the background with black. Ohh i forgot: If you rotate, you have to specify an backgroundcolor by imagecolorallocatealpha(!) and set imagealphablending to false and imagesavealpha to true to get an transparent rotated png... Reproduce code: --- Expected result: This works fine and copys a transparent PNG with 35 degree to the new test.png. If you change now $rot = 35 to $rot = 46 the rotated png will appear on an black background. -- Edit this bug report at http://bugs.php.net/?id=32921&edit=1