#21470 [Opn->Csd]: add imagecopyrotated from latest gd
ID: 21470 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.0 -Assigned To: +Assigned To: pajoye New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Hello, We strongly recommand the use of the bundled GD, which includes imagerotate. Thank's for your report. pierre Previous Comments: [2003-01-06 14:14:23] [EMAIL PROTECTED] http://www.boutell.com/gd/ has a patch against php 4.2.3 that adds the imagecopyrotated() function from the gdImageCopyRotated() function that was added in gd 2.0.8. I would be nice if this were a part of the php tree. -- Edit this bug report at http://bugs.php.net/?id=21470&edit=1
#21524 [Opn->Asn]: Add imagesavealpha so that imagepng can output alpha channel
ID: 21524 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0 -Assigned To: +Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Hello, This feature will be present in futur version of php (means not any upcoming bugfixes releases) using the bundled GD. Thank's for your report, pierre Previous Comments: [2003-01-08 13:22:36] [EMAIL PROTECTED] (Not sure whether this should be here or under GD related) It would be useful if PHP had access to the gdSaveAlpha function in the GD library. Using PHP 4.3.0 with bundled GD, there is currently no way I can see to prevent imagepng stripping the alpha channel of a truecolor image. The following script produces a white circle on a black background, rather than a semi-transparent circular 'hole': According to the GD change list at http://www.boutell.com/gd/manual2.0.9.html#whatsnew2.0.2 this is the correct default behaviour since version 2.0.2 - there is a function gdSaveAlpha to turn on and off alpha output which appears to be present in the bundled GD in CVS but at the moment without any PHP wrapper. A PHP function imagesavealpha(resource image, bool savealpha) would allow alpha output when required without breaking any existing scripts. -S. Haydon -- Edit this bug report at http://bugs.php.net/?id=21524&edit=1
#21729 [Opn]: imagettftext don't work with a image copied resized from another
ID: 21729
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: Linux
PHP Version: 4.3.0
New Comment:
Hello,
Can you provide a small script to reproduce your problem, this function
works like a charm here.
This line:
$tc = ImageColorAllocate ($im, $colors[$color][0],
$colors[$color][1], $colors[$color][2]);
can be your problem. Check the $color array, or set
error_reporting(E_ALL); to see if they are initialized correctly (btw,
use always this flag to develop).
Second point, ImageAlphaBlending is useless in your case,
ImageColorAllocate allocates a color with an opaque alpha channel.
thank's for your interest,
pierre
Previous Comments:
[2003-01-19 07:27:08] [EMAIL PROTECTED]
Don't show the text also with the latest CVS version.
[2003-01-18 13:17:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-01-18 11:17:51] [EMAIL PROTECTED]
This code work fine on PHP 4.2.3 compiled with gd2.0.4, but give a
image without text with php 4.3 compiled with internal gd support. I
have this problem only in the image resized and not with the original
image:
if($width==$isize[0]) //original size: this work
{
$im = ImageCreateFromPNG ("bottoni/".$tipo_bottone);
}
else // to resize: don't work
{
$im1 = ImageCreateFromPNG("bottoni/".$tipo_bottone);
$im=ImageCreateTrueColor($width, $isize[1]);
ImageCopy($im, im1,0,0,0,0,$margin_width,$isize[1]);
ImageCopyResized($im, $im1, $margin_width, 0, $margin_width, 0,
$width, $isize[1], round($isize[0]-($margin_width * 2),0), $isize[1]);
ImageCopy($im,
$im1,$margin_width+$width-1,0,$isize[0]-$margin_width,0,$margin_width,$isize[1]);
ImageDestroy($im1);
}
ImageAlphaBlending($im, true);
$tc = ImageColorAllocate ($im, $colors[$color][0],
$colors[$color][1], $colors[$color][2]);
imagettftext($im, $size, 0, $center, $margin_height, $tc,
$currpath."/fonts/".$font,$testo);
ImageAlphaBlending($im, false);
header("Content-Type: image/png\n\n");
ImagePNG($im);
Thank for support
Paolo Morandi
--
Edit this bug report at http://bugs.php.net/?id=21729&edit=1
#22103 [Opn->Ver]: imagefilledellipse() is incorrect with alpha blending
ID: 22103 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Verified Bug Type: GD related Operating System: Linux PHP Version: 4.3.0 New Comment: Hello, Thank's for the report. I have already solved this problem with a quit nice and fast algorithm. I have to check if I can add it to the current 4_3 HEAD. Doing something better with ellipse then what GD currently does is not very difficult (actually it's nothing else than a filled polygon with many connected lines, kind of ugly things to draw a simple ellipse). pierre Previous Comments: [2003-02-07 11:06:00] [EMAIL PROTECTED] I had a look in the source in GD. The problem is the way the gdImageFilledArc() is implemented. The algorithm there is flawed for alpha-blending. It fills the arc by drawing a series of filled polygons (triangles) centerd in the middle of the ellipse and out to the edge of the ellipse with 1 degree separation between the end points. This will make the interior points overlap and create the moire pattern. Unfortunately there isn't a simple solution to this. Doing a floodfill to a specific color wan't work since we don't know the canvas we are drawing on. Since I'm doing a lot of graphic stuff I'll see if I can come up with a new algorithm to do this. I'm afraid however that any correct algortihm will be quite CPU expensive. [2003-02-07 09:44:44] [EMAIL PROTECTED] The problem still exist in snapshot 200302071430. I haven't had time to look at the GD code but this is most likely a design flaw and not a straight bug. Fixing this will probably require a new fill algorithm for ellipses that can guarantee that the same pixel inside the ellipse will only be painted exactly one time. The script below demonstrates this bug and the resulting image can also be viewed at http://www.aditus.nu/jpgraph/bbimages/filledellipsebug.png [2003-02-07 06:36:22] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip There were couple of fixes in GD in CVS. If it still fails, please provide a short example script. [2003-02-06 22:18:03] [EMAIL PROTECTED] (Using built-in GD 2.x in PHP 4.3.0) imagefilledellipse() creates moire' patterns inside the filled ellipse when alpha blending is enabled. The problem seems to be that the fill algorithm strokes the same point within the ellipse several times and due to the alpha blending of single pixels creates several color shades within the ellipse. This is fine as long as a solid fill is used but does not work together with alpha blending. -- Edit this bug report at http://bugs.php.net/?id=22103&edit=1
#22103 [Ver]: imagefilledellipse() is incorrect with alpha blending
ID: 22103
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: GD related
Operating System: Linux
PHP Version: 4.3.0
New Comment:
I thank you for your function, but hopefully there is a far better way
to draw ellipse or circle.
As I said, I have to check if I can commit new functions to the head.
As far as it's OK, I'll commit.
hth
pierre
Previous Comments:
[2003-02-07 20:42:06] [EMAIL PROTECTED]
Hm.. I didn't see that ou already had made a fix in the head for this.
I haven't looked at your solution but I guess it's probably the same as
mine. When I turned on my brain the solution is of course obvious once
you know that FilledPolygon() actually does a correct fill.
BTW Do you agree with me that the behavior that
a filled style with IMG_ARC_CHORD should be the same as
IMG_ARC_PIE ? (The current behaviour.) I cosider this a bug since if
you set the CHORD style it should fill just the CHORD and not complete
the slice to the center. Just a minor detail.
I would rather consider this a bug
[2003-02-07 20:36:05] [EMAIL PROTECTED]
I wrote a drop in replacement for the GD gdImageFilledArc() which works
with alpha-blending. Replace the gdImageFilledArc() in gd.c with the
following function. Which is reasonable fast.
void
gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s,
int e, int color, int style)
{
/*
This replacement for the original gdImageFilledArc() completely
mimics
the original behavior. This includes the behaviour I would
consider a bug
where a style of IMG_ARC_CHORD is the same as IMG_ARC_PIE for
filled arcs.
The benefit of this implementation is that this will also work
for
colors where alpha-blending is used.
This algorithm uses GD standard sin & cos tables for quick
lookup.
However, this also limits the accuracy to 1 degree. This means
that
very very large arc's will look "squarish". However for any
normal
sizes, say < 2000 pixels, this is not really a problem in
practice.
*/
gdPoint p[362];
/* Sanity check */
if( w < 0 || h < 0 ) return;
/* Make sure angles are positive and e > s */
while( s < 0 ) s += 360;
while( e < 0 ) e += 360;
while( e < s ) e += 360;
s %= 360;
if( e > 360 )
e %= 360;
/* In the algorithm we need to ue the radius */
w /= 2;
h /= 2;
/* We handle the chord and pie cases separately */
if( style & gdChord ) {
int x1,y1,x2,y2;
x1 = cx + ((long) gdCosT[s] * (long) w / 1024 );
y1 = cy + ((long) gdSinT[s] * (long) h / 1024 );
x2 = cx + ((long) gdCosT[e] * (long) w / 1024 );
y2 = cy + ((long) gdSinT[e] * (long) h / 1024 );
if( style & gdNoFill ) {
if( style & gdEdged ) {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImagePolygon (im, p, 4, color);
}
else {
gdImageLine (im, x1, y1, x2, y2, color);
}
}
else {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImageFilledPolygon (im, p, 4, color);
}
}
else {
/* style must be gdPie */
int i=0, a=s;
if( style & gdEdged || ! (style & gdNoFill) ) {
p[0].x = cx; p[0].y = cy;
i=1;
}
while( a <= e ) {
p[i].x = cx + ((long) gdCosT[a] * (long) w / 1024 );
p[i].y = cy + ((long) gdSinT[a] * (long) h / 1024 );
++i;
++a;
}
if( style & gdEdged || ! (style & gdNoFill) ) {
p[i].x = cx; p[i].y = cy;
++i;
}
if( style & gdNoFill ) {
gdImagePolygon (im, p, i, color);
}
else {
gdImageFilledPolygon (im, p,i , color);
}
}
}
[2003-02-07 20:16:15] [EMAIL PROTECTED]
Hello,
Thank's for the report.
I have already solved this problem with a quit nice and fast algorithm.
I have to check if I can add it to the current 4_3 HEAD.
Doing something better with ellipse then what GD currently does is not
very difficult (actually it's nothing else than a filled polygon with
many connected lines, kind of ugly things to draw a simple ellipse).
pierre
-
#22103 [Ver->Csd]: imagefilledellipse() is incorrect with alpha blending
ID: 22103
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Closed
Bug Type: GD related
Operating System: Linux
PHP Version: 4.3.0
-Assigned To:
+Assigned To: pajoye
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-02-07 21:26:46] [EMAIL PROTECTED]
I thank you for your function, but hopefully there is a far better way
to draw ellipse or circle.
As I said, I have to check if I can commit new functions to the head.
As far as it's OK, I'll commit.
hth
pierre
[2003-02-07 20:42:06] [EMAIL PROTECTED]
Hm.. I didn't see that ou already had made a fix in the head for this.
I haven't looked at your solution but I guess it's probably the same as
mine. When I turned on my brain the solution is of course obvious once
you know that FilledPolygon() actually does a correct fill.
BTW Do you agree with me that the behavior that
a filled style with IMG_ARC_CHORD should be the same as
IMG_ARC_PIE ? (The current behaviour.) I cosider this a bug since if
you set the CHORD style it should fill just the CHORD and not complete
the slice to the center. Just a minor detail.
I would rather consider this a bug
[2003-02-07 20:36:05] [EMAIL PROTECTED]
I wrote a drop in replacement for the GD gdImageFilledArc() which works
with alpha-blending. Replace the gdImageFilledArc() in gd.c with the
following function. Which is reasonable fast.
void
gdImageFilledArc (gdImagePtr im, int cx, int cy, int w, int h, int s,
int e, int color, int style)
{
/*
This replacement for the original gdImageFilledArc() completely
mimics
the original behavior. This includes the behaviour I would
consider a bug
where a style of IMG_ARC_CHORD is the same as IMG_ARC_PIE for
filled arcs.
The benefit of this implementation is that this will also work
for
colors where alpha-blending is used.
This algorithm uses GD standard sin & cos tables for quick
lookup.
However, this also limits the accuracy to 1 degree. This means
that
very very large arc's will look "squarish". However for any
normal
sizes, say < 2000 pixels, this is not really a problem in
practice.
*/
gdPoint p[362];
/* Sanity check */
if( w < 0 || h < 0 ) return;
/* Make sure angles are positive and e > s */
while( s < 0 ) s += 360;
while( e < 0 ) e += 360;
while( e < s ) e += 360;
s %= 360;
if( e > 360 )
e %= 360;
/* In the algorithm we need to ue the radius */
w /= 2;
h /= 2;
/* We handle the chord and pie cases separately */
if( style & gdChord ) {
int x1,y1,x2,y2;
x1 = cx + ((long) gdCosT[s] * (long) w / 1024 );
y1 = cy + ((long) gdSinT[s] * (long) h / 1024 );
x2 = cx + ((long) gdCosT[e] * (long) w / 1024 );
y2 = cy + ((long) gdSinT[e] * (long) h / 1024 );
if( style & gdNoFill ) {
if( style & gdEdged ) {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImagePolygon (im, p, 4, color);
}
else {
gdImageLine (im, x1, y1, x2, y2, color);
}
}
else {
p[0].x = cx; p[0].y = cy;
p[1].x = x1; p[1].y = y1;
p[2].x = x2; p[2].y = y2;
p[3].x = cx; p[3].y = cy;
gdImageFilledPolygon (im, p, 4, color);
}
}
else {
/* style must be gdPie */
int i=0, a=s;
if( style & gdEdged || ! (style & gdNoFill) ) {
p[0].x = cx; p[0].y = cy;
i=1;
}
while( a <= e ) {
p[i].x = cx + ((long) gdCosT[a] * (long) w / 1024 );
p[i].y = cy + ((long) gdSinT[a] * (long) h / 1024 );
++i;
++a;
}
if( style & gdEdged || ! (style & gdNoFill) ) {
p[i].x = cx; p[i].y
#21560 [Opn]: imagettfbbox() returns different values in 4.3.0 and 4.2.1
ID: 21560 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: SusE 8.0 PHP Version: 4.3.0 New Comment: Hi, Can you provide a link with the test script and the font used ? thank's pierre Previous Comments: [2003-02-07 10:03:02] [EMAIL PROTECTED] The problem still exists in snapshot 200302071430 for the _exact_ same text string imagettfbbox() (and the _exact_ same test script) returns the following (different) values depending on version of PHP and GD Snapshot 200302071430 Array ( [0] => -1 [1] => 14 [2] => -1 [3] => -226 [4] => -16 [5] => -226 [6] => -16 [7] => 14 ) PHP 4.3 (official release) Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -226 [4] => -16 [5] => -226 [6] => -16 [7] => 13 ) PHP 4.2.3 (with GD 2.01) Array ( [0] => 3 [1] => -1 [2] => 3 [3] => -234 [4] => -16 [5] => -234 [6] => -16 [7] => -2 ) The only correct values are with GD 2.01 for both PHP 4.3 and snapshot the bounding box is incorrect since it starts 14 (in snapshot) or 13 (in 4.3) pixels in into the text. [2003-01-27 22:39:59] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-01-09 20:11:36] [EMAIL PROTECTED] Try non-bundled gd 2.0.9 and see if you get the same results as the ones you've got with bundled GD library. I suspect that the behaviour of GD between 2.0.1 and later versions had changed. [2003-01-09 18:59:27] [EMAIL PROTECTED] For the given string string "Demonstration of different\ntext of two lines" (ArialTTF font font 90 degrees rotation containing two lines separated by a single "\n".) The imagettfbbox() returns different value arrays in PHP 4.2.1 using GD 2.01 and PHP 4.3.0 using builtin GD 2.08+ (You get the same difference for 4.2.1 by using GD 2.08 so the problem must be in GD 2.08) For GD 2.01 it returns (29,-1,29,-279,-20,-279,-20,-1) For GD 2.08+ it returns (29,18,29,-277,-21,-277,-21,18) [2003-01-09 18:49:49] [EMAIL PROTECTED] For the given string string "Demonstration of different\ntext of two lines" (ArialTTF font font 90 degrees rotation containing two lines separated by a single "\n".) The imagettfbbox() returns different value arrays in PHP 4.2.1 using GD 2.01 and PHP 4.3.0 using builtin GD 2.08+ (You get the same difference for 4.2.1 by using GD 2.08 so the problem must be in GD 2.08) For GD 2.01 it returns (-29,18,29,-277,-21,-277,-21,18) For GD 2.08+ it returns (-29,18,29,-279,-20,-279,-20,-1) -- Edit this bug report at http://bugs.php.net/?id=21560&edit=1
#22315 [Opn]: weird errors using \\
ID: 22315
Updated by: [EMAIL PROTECTED]
Reported By: paj at pearfr dot org
Status: Open
Bug Type: PCRE related
Operating System: linux
PHP Version: 4.3.1
New Comment:
The 2nd script seems to work on 4.2.1, 4.2.2, 4.2.3, 4.3.0 and 4.3.1.
Well, I can consider it as the way to do it.
pierre
Previous Comments:
[2003-02-19 22:51:15] paj at pearfr dot org
$path='Hello\ World There is\ a\ dog';
$split=preg_split('/(?http://devel.akbkhome.com/regex.php
which runs 4.3.0, the 1st expression works correclty
pierre
--
Edit this bug report at http://bugs.php.net/?id=22315&edit=1
#20451 [Opn->Csd]: imagepstext generates weird images since PHP 4.3.0-pre1
ID: 20451 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Red Hat Linux 7.3 PHP Version: 4.3.0RC1 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Hello, I have downloaded your script (which is bugged, the path to the font is wrong generated, removed +1 :) ), I do not see any problem with the font (except the fact, as you said, it s an ugly font). I compared the result with a font viewer as well as a paint program, no problem occurs. Tests made with RC2, RC1 and HEAD. pierre Previous Comments: [2002-11-18 15:07:12] [EMAIL PROTECTED] Verified that the problem still exists in PHP 4.3.0RC1. [2002-11-16 13:44:42] [EMAIL PROTECTED] Reopening the report [2002-11-15 23:06:10] [EMAIL PROTECTED] I forgot to mention that I use t1lib 1.3.1 from the following address to enable the imageps* functions in the gd extension (--with-t1lib configure option): ftp://sunsite.unc.edu/pub/Linux/libs/graphics/t1lib-1.3.1.tar.gz [2002-11-15 23:03:00] [EMAIL PROTECTED] Yes, certainly, here's the whole code and the font in question: http://web.axelero.hu/fdsoft/temp/fonttest.zip There are some really ugly calculations and a brute force way of determining the size of the would-be image in the code, since imagepsbbox function didn't quite work well either. At least that was the case with PHP 4.2.x, and since I added this workaround, I've yet to re-check that in 4.3.0. Now for this weird output problem I can't figure out a workaround, and this was absolutely perfect with PHP 4.2.x., hence my bug report. It's likely that the fonts I use are of low quality or buggy or both; but that doesn't change the fact that this was working nicely with the older versions. Thanks [2002-11-15 21:18:24] [EMAIL PROTECTED] Can you please provide a complete and working example script? This one you added does not work. --Jani The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20451 -- Edit this bug report at http://bugs.php.net/?id=20451&edit=1
#20847 [Opn->Csd]: subimages made from transparent images aren' transparent
ID: 20847 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Debian (sid) Linux 2.4.20 PHP Version: 4.3.0RC2 -Assigned To: +Assigned To: pajoye New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. hello, You may use color to draw something in a image, not only alpha channels. Paint program shows you a black/gray for ot as a convenience. Try to redraw your letter with real color (even with transparancy) and it will work. Thank's for your report. pierre Previous Comments: [2002-12-05 17:52:48] [EMAIL PROTECTED] Additional note: If I try to directly copy the transparent png image over the photo image, it works like a charm, it's only when I need to create an intermediate subimage that it doesn't work. [2002-12-05 17:49:10] [EMAIL PROTECTED] I'm running 4.3.0RC2 with the built in gd library. What I'm trying to do is create a transparent subimage from a series of pngs that have an 8 bit alpha channel. I then can resize the subimage, rotate it, whatever over another photograph. I realize there's the imagecolortransparent() function so you can specify one color on your image as transparent, but this does not help the case when you want full 8-bit transparency. Expected results: The subimage should have an 8-bit alpha channel like the png's that's it's created from and should be transparent when imagecopy()'d over the photoimage. Actual results: I get a black box where I tried to copy the image. Web page source: http://pimpbot.qooqle.com/gid/php_bug1/ (example png and jpg images I used are loacated here) Example source: -- Edit this bug report at http://bugs.php.net/?id=20847&edit=1
#20880 [Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic
ID: 20880 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Mac OSX 10.2.2 PHP Version: 4.2.3 New Comment: These 2 links pointed you to the latest development version of php. The 1st link is the linux sources, the 2nd in the windows binary version (which you can use on a windows box as a full replacement of your current installation for tests purpose). In the case you will test with one these version, please use the bundled gd library (compile with "--with-gd" to get it). Then can you try to export it as a png image and post an url here ? pierre You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? Previous Comments: [2002-12-07 19:11:32] [EMAIL PROTECTED] Try what? You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? Rüdiger [2002-12-07 17:34:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Download the latest PHP snapshot from the URL in this message and try it. [2002-12-07 17:22:44] [EMAIL PROTECTED] Thanks for fast response. What did you mail me? Source code? I do not know what to do with it. Sorry, Rüdiger [2002-12-07 15:09:50] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Please use the bundled gd included with the STABLE snapshot. [2002-12-07 12:36:23] [EMAIL PROTECTED] I have two png-files, both with transparency. With ImageCopy the transparency area of the second graphic will dominate the white area of the first graphic at the bottom. Example at http://rc.opelgt.org/rechnereien/bug.gif in the left bottom (origin) of the diagramm: Ok: at the left GD 1.6 with GIFs, bad: at the right GD 2.0 with PNGs. My suggestion: a switch to set the behavior 1. transparency of the second leaves the bottom grafic unmodified. Good for my application. 2. transparency of the second grafic dominates the first grafic. Good for perforating the first grafic With kind regards, Rüdiger The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20880 -- Edit this bug report at http://bugs.php.net/?id=20880&edit=1
#20880 [Opn]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic
ID: 20880 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: Mac OSX 10.2.2 PHP Version: 4.2.3 New Comment: Hello, A quick test helpfull to find out what happens with your image, can you provide a url (html page) with the 2 original images you use to create the final gif image you provided as a link, and a short script to reproduce it. About a compiler on a macos platform, you may take a look at: http://www.phpmac.com/ pierre Previous Comments: [2002-12-07 19:45:20] [EMAIL PROTECTED] Hello Pierre, as mentioned I have a Mac and using a C-Compiler is beyond my possibilities. I will wait for 4.3 as a Mac-Version. Rüdiger P.s.: Or do you have a source for a free C-Compiler for Mac OSX? [2002-12-07 19:30:53] [EMAIL PROTECTED] These 2 links pointed you to the latest development version of php. The 1st link is the linux sources, the 2nd in the windows binary version (which you can use on a windows box as a full replacement of your current installation for tests purpose). In the case you will test with one these version, please use the bundled gd library (compile with "--with-gd" to get it). Then can you try to export it as a png image and post an url here ? pierre You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? [2002-12-07 19:11:32] [EMAIL PROTECTED] Try what? You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? Rüdiger [2002-12-07 17:34:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Download the latest PHP snapshot from the URL in this message and try it. [2002-12-07 17:22:44] [EMAIL PROTECTED] Thanks for fast response. What did you mail me? Source code? I do not know what to do with it. Sorry, Rüdiger The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20880 -- Edit this bug report at http://bugs.php.net/?id=20880&edit=1
#20880 [Opn->Csd]: In ImageCopy transparency of the top grafic dominates color of the bottom grafic
ID: 20880 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Mac OSX 10.2.2 PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The current cvs works well with the provided images. Try your script with the cvs version. Thank's the report, pierre Previous Comments: [2002-12-08 02:37:29] [EMAIL PROTECTED] The application is at http://rc.opelgt.org/rechnereien/tacho.html The two gifs are at http://rc.opelgt.org/rechnereien/diagramm.gif and http://rc.opelgt.org/rechnereien/verdeck.gif The two pngs are at http://rc.opelgt.org/rechnereien/diagramm.png and http://rc.opelgt.org/rechnereien/verdeck.png The php code is A test html page for easy viewing with dark background The two pngs are created with Adobe PhotoShop 6. I tried to solve the problem with different colors in the two pings marked as transparent (before both #00FF00) but without success. Rüdiger [2002-12-07 20:46:08] [EMAIL PROTECTED] Hello, A quick test helpfull to find out what happens with your image, can you provide a url (html page) with the 2 original images you use to create the final gif image you provided as a link, and a short script to reproduce it. About a compiler on a macos platform, you may take a look at: http://www.phpmac.com/ pierre [2002-12-07 19:45:20] [EMAIL PROTECTED] Hello Pierre, as mentioned I have a Mac and using a C-Compiler is beyond my possibilities. I will wait for 4.3 as a Mac-Version. Rüdiger P.s.: Or do you have a source for a free C-Compiler for Mac OSX? [2002-12-07 19:30:53] [EMAIL PROTECTED] These 2 links pointed you to the latest development version of php. The 1st link is the linux sources, the 2nd in the windows binary version (which you can use on a windows box as a full replacement of your current installation for tests purpose). In the case you will test with one these version, please use the bundled gd library (compile with "--with-gd" to get it). Then can you try to export it as a png image and post an url here ? pierre You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? [2002-12-07 19:11:32] [EMAIL PROTECTED] Try what? You have sent me twice the same link. When I have no C-Compiler (or what kind of source is this?) what shall I do with it? Rüdiger The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20880 -- Edit this bug report at http://bugs.php.net/?id=20880&edit=1
#20472 [Opn]: Flood Fill problem after changing to 4.3.0RC1
ID: 20472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: RedHat Linx 7.2 PHP Version: 4.3.0RC1/3 New Comment: Hello, Can you provide the original image (in the original format) ? I saw little difference (well I expect differences while analyzing the 2 results). pierre Previous Comments: [2002-12-15 16:12:31] [EMAIL PROTECTED] To see the results of the different installations, please execute these pages. You may need to do a full refresh (Ctrl-Refresh) http://www.wisnowmobileclubs.com:88/refresh.php for Dev. http://www.wisnowmobileclubs.com/refresh.php for Prod. [2002-12-15 16:01:07] [EMAIL PROTECTED] Well, I have gotten everything to compile & make with using the --with-gd option. But I am still having a problem with the flood fill. With PHP 4.2.3 the flood fill works fine... with the new versions of PHP the flood fill does not work. I will try to create a script that can reproduce this. http://www.wisnowmobileclubs.com/picture.htm show the differences in the images. [2002-12-15 15:31:21] [EMAIL PROTECTED] You can 'fix' that problem by adding --with-jpeg-dir=/usr (if libjpeg is located in /usr/lib and the include files in /usr/include). [2002-12-15 15:28:23] [EMAIL PROTECTED] Using the --with-gd & --with-zlib did allow PHP-4.3.0RC3 to compile & make correctly. My code, which does work in production, does not work with this combination. I receive the following error: Fatal error: Call to undefined function: imagejpeg() in /home/wisnowmobileclubs.com/func/reportedplace.fun on line 368 I am still going to work with the most recent stable version & the --with-gd=path option. [2002-12-15 14:26:49] [EMAIL PROTECTED] --with-gd=/path uses an external library you already have installed on your system. --with-gd will use the bundled version of GD; from PHP 4.3.0 we bundle GD with our own patches and bugfixes. If you do not need GIF writing support we strongly recommend to use the bundled library as it has some fixes and new features (like anti-aliased line drawing) that the non-bundled library does not have. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20472 -- Edit this bug report at http://bugs.php.net/?id=20472&edit=1
#20472 [Opn]: Flood Fill problem after changing to 4.3.0RC1
ID: 20472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: RedHat Linx 7.2 PHP Version: 4.3.0RC1/3 New Comment: Hello, After a little test of imagefill, I can say it works as expected. We can invoke the bad quality of the original images (lines and noises) as a reason for this problem. I m waiting feedbacks for a final test with a clean & well formed images before closing (I hope :) this bug pierre Previous Comments: [2002-12-17 21:51:25] [EMAIL PROTECTED] I have updated the script to output the orginial image below the php edited image. The differences in the 2 images is the back ground. The back ground should be white, not red as seen in the image created with this link. http://www.wisnowmobileclubs.com:88/refresh.php I have been able to re-create this problem by running the two different scripts on both IE 6 and Netscape 6. If the images look the same, please do a full refresh of each page to force pull the image from the server rather than cache. Thanks [2002-12-16 19:59:22] [EMAIL PROTECTED] Hello, Can you provide the original image (in the original format) ? I saw little difference (well I expect differences while analyzing the 2 results). pierre [2002-12-15 16:12:31] [EMAIL PROTECTED] To see the results of the different installations, please execute these pages. You may need to do a full refresh (Ctrl-Refresh) http://www.wisnowmobileclubs.com:88/refresh.php for Dev. http://www.wisnowmobileclubs.com/refresh.php for Prod. [2002-12-15 16:01:07] [EMAIL PROTECTED] Well, I have gotten everything to compile & make with using the --with-gd option. But I am still having a problem with the flood fill. With PHP 4.2.3 the flood fill works fine... with the new versions of PHP the flood fill does not work. I will try to create a script that can reproduce this. http://www.wisnowmobileclubs.com/picture.htm show the differences in the images. [2002-12-15 15:31:21] [EMAIL PROTECTED] You can 'fix' that problem by adding --with-jpeg-dir=/usr (if libjpeg is located in /usr/lib and the include files in /usr/include). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20472 -- Edit this bug report at http://bugs.php.net/?id=20472&edit=1
#20472 [Opn->Csd]: Flood Fill problem after changing to 4.3.0RC1
ID: 20472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: RedHat Linx 7.2 PHP Version: 4.3.0RC1/3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Not a clean image and non closed lines caused this problem. Thank's for your report, and do not forget to use only the bundled in the futur ;-) pierre Previous Comments: [2002-12-17 23:04:24] [EMAIL PROTECTED] I have changed my image in a couple places to ensure that there was a solid line around the area I was issuing the flood fill. This has fixed the problem with the flood fill filling areas that I did not intend to be filled. Although the problem no-longer appears to be with the flood fill, I am curious at to why the two versions of php work differently. Was something changed in php (or the bundled gd) to require a more 'solid' line? Could this be a bug, or a un-intended side effect? Thanks for all the help that has been provided. [2002-12-17 22:33:58] [EMAIL PROTECTED] Hello, After a little test of imagefill, I can say it works as expected. We can invoke the bad quality of the original images (lines and noises) as a reason for this problem. I m waiting feedbacks for a final test with a clean & well formed images before closing (I hope :) this bug pierre [2002-12-17 21:51:25] [EMAIL PROTECTED] I have updated the script to output the orginial image below the php edited image. The differences in the 2 images is the back ground. The back ground should be white, not red as seen in the image created with this link. http://www.wisnowmobileclubs.com:88/refresh.php I have been able to re-create this problem by running the two different scripts on both IE 6 and Netscape 6. If the images look the same, please do a full refresh of each page to force pull the image from the server rather than cache. Thanks [2002-12-16 19:59:22] [EMAIL PROTECTED] Hello, Can you provide the original image (in the original format) ? I saw little difference (well I expect differences while analyzing the 2 results). pierre [2002-12-15 16:12:31] [EMAIL PROTECTED] To see the results of the different installations, please execute these pages. You may need to do a full refresh (Ctrl-Refresh) http://www.wisnowmobileclubs.com:88/refresh.php for Dev. http://www.wisnowmobileclubs.com/refresh.php for Prod. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20472 -- Edit this bug report at http://bugs.php.net/?id=20472&edit=1
#22436 [Opn]: Valid solution for working with < 1969 dates
ID: 22436 Updated by: [EMAIL PROTECTED] Reported By: ivo at ibuildings dot nl Status: Open Bug Type: Feature/Change Request Operating System: Redhat Linux PHP Version: 4.3.0 New Comment: Hello, As a sidenote, I just commited pecl/date which support date ranges lower than unix Epoc. Win32 snaps are available through http://snaps.php.net/win32/PECL_UNSTABLE/ hth pierre Previous Comments: [2003-02-28 02:13:01] ivo at ibuildings dot nl There's a library (part of adodb) to work around the negative date problem on windows. It can be modified to perform the same functionality on linux, when mktime does not work as expected there. This lib can be found here: http://php.weblogs.com/adodb_date_time_library Perhaps this functionality can be made a standard in php? In other words, make mktime behave exactly like the adodb_mktime function from this library etc.? [2003-02-26 09:26:08] [EMAIL PROTECTED] Just a a note, PEAR has a date class capable of handling dates prior to 1969. [2003-02-26 08:22:23] ivo at ibuildings dot nl Hi, working with dates before 1970 with mktime sometimes works, sometimes doesn't. There are several bugs in the bug database describing this problem: bug #18802, bug #22163 and bug #20280. All are answered with stuff like "behaviour of mktime before 1970 is undefined", "it's not a php bug because it's due to glibc" etc. While all of these are most certainly true, it's not really a helpful answer to php users. PHP users just want to do stuff with dates. When working with birthdates, dates from before 1970 are quite common. Therefor, I request that the php date/time functions will be made such that they *work*, regardless of the operating system, the glibc version etc. Would you please consider doing this? -- Edit this bug report at http://bugs.php.net/?id=22436&edit=1
#27112 [Opn->Bgs]: Problem with GD in php
ID: 27112 Updated by: [EMAIL PROTECTED] Reported By: mankaho at lskcf5d dot net -Status: Open +Status: Bogus Bug Type: GD related Operating System: Linux Mandrake PHP Version: 4.3.4 New Comment: See the manual about the configuration directive and the memory limit. Previous Comments: [2004-02-01 02:00:15] mankaho at lskcf5d dot net Description: I use a GD in PHP: PHP Version 4.3.3 I get an error with can't allocate memory PHPconfig: http://expt.lskc.edu.hk/~l99534/info.php Reproduce code: --- Expected result: I smaller photo will be generated.. on web browser Actual result: -- Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 4096 bytes) in /var/www/html/2003/5d/test/test.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=27112&edit=1
#27112 [Bgs]: Problem with GD in php
ID: 27112 Updated by: [EMAIL PROTECTED] Reported By: mankaho at lskcf5d dot net Status: Bogus Bug Type: GD related Operating System: Linux Mandrake PHP Version: 4.3.3 New Comment: It's php.ini. Other questions should be posted on the php general list. hth pierre Previous Comments: [2004-02-01 06:03:36] mankaho at lskcf5d dot net Is is the php.ini or apache2 problem? Which file should i config .. ?The pgp.ini or httpd.? [2004-02-01 04:30:09] [EMAIL PROTECTED] See the manual about the configuration directive and the memory limit. [2004-02-01 02:00:15] mankaho at lskcf5d dot net Description: I use a GD in PHP: PHP Version 4.3.3 I get an error with can't allocate memory PHPconfig: http://expt.lskc.edu.hk/~l99534/info.php Reproduce code: --- Expected result: I smaller photo will be generated.. on web browser Actual result: -- Fatal error: Allowed memory size of 8388608 bytes exhausted at (null):0 (tried to allocate 4096 bytes) in /var/www/html/2003/5d/test/test.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=27112&edit=1
#26665 [Opn]: php crashes with large files and array work (2MB Script File). win32 works.
ID: 26665 Updated by: [EMAIL PROTECTED] Reported By: fschaper at intux dot org Status: Open Bug Type: Reproducible crash Operating System: * PHP Version: 4CVS, 5CVS New Comment: Hello, PHP ""should"" not crash in this case. However I missed your conception of a cache. I suggest you to look at a database, ie sqlite. I hope you do not use this kind of """cache""" too much. pierre Previous Comments: [2004-02-05 16:34:11] [EMAIL PROTECTED] I can reproduce this at will. It is not a memory issue as I can create the array in code with ease and not crash. I can also split the file into several files and all is ok. It is only when I try to load a large file (~2.8MB for me) that PHP crashes. I provide the following test file that is 4MB+ that crashes every time. http://spidey.dealnews.com/~brianm/php_large_file_crash.php.txt As you will see, I have an early call to exit() in that file. That nor the echo ever happens. I ran this with and without my custom php.ini file. My PHP version info: $ php -v PHP 4.3.4 (cli) (built: Feb 5 2004 16:00:45) (DEBUG) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies gdb did not give me much: (gdb) run Starting program: /usr/local/bin/php php_large_file_crash.php.txt Program received signal SIGSEGV, Segmentation fault. execute (op_array=0x8221834) at /usr/src/apache/php-4.3.4/Zend/zend_execute.c:1071 1071zend_clean_garbage(TSRMLS_C); We generate large amounts of cached arrays in files. This is the first time this has happened as far as I know. [2003-12-30 10:26:38] [EMAIL PROTECTED] Does not crash for me. And the example script is pretty useless anyway, you really should be using error_reporting = E_ALL once.. [2003-12-22 07:59:26] fschaper at intux dot org This Bug can be repoduduced under Window's as well, only the file-size has to be larger (will depend on system memory etc.). I have tried it with an 8MB version (might as well take less than that) of the script (the one I added the link to) and PHP crashes under Windows as well. [2003-12-19 09:59:05] fschaper at intux dot org This time I ran the script via the shell without apache (gdb) bt #0 0x0811f8f6 in execute (op_array=0x819841c) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend_execute.c:1758 #1 0x0810fa28 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend.c:884 #2 0x080ed1d3 in php_execute_script (primary_file=0xbcf8) at /usr/src/debug/php4-STABLE-200312191430/main/main.c:1729 #3 0x08125eb3 in main (argc=2, argv=0xbd74) at /usr/src/debug/php4-STABLE-200312191430/sapi/cgi/cgi_main.c:1578 (gdb) frame 0 #0 0x0811f8f6 in execute (op_array=0x819841c) at /usr/src/debug/php4-STABLE-200312191430/Zend/zend_execute.c:1758 1758ALLOC_ZVAL(valptr); [2003-12-19 04:36:10] fschaper at intux dot org Description: While working with "many" array's (around 2MB of code) we encountered a crash on linux-systems while everything works fine under windows. PHP silently fails - only error log is the apache segfault. Apache 1.3.28 PHP 4.3.3 Reproduce code: --- http://www.intux.org/tmp/php_segf_test.tar.gz 100 Lines of code works Around 103 lines and more and it starts to break down Expected result: The last PHP command should write an "done" on the page. Actual result: -- An empty document should be returned since apache simply crashes -- Edit this bug report at http://bugs.php.net/?id=26665&edit=1
#22066 [NoF]: GD 2.0.11 with php 4.3.0
ID: 22066 Updated by: [EMAIL PROTECTED] Reported By: khin-shein dot khin at st dot com Status: No Feedback Bug Type: GD related Operating System: Solaris 2.7 PHP Version: 4.3.0 New Comment: > I keep getting this error, too, using the latest gd 2.0.22 > (as well as gd 2.0.21) and php 4.3.4 on Suse Linux 8.1 > (heavily modified). Using bundled GD (configure --with-gd), you do not need any external GD. And be sure you do not have GD includes in your include path, those may override the bundled ones. pierre Previous Comments: [2004-02-08 07:17:56] gz at data-development dot de I keep getting this error, too, using the latest gd 2.0.22 (as well as gd 2.0.21) and php 4.3.4 on Suse Linux 8.1 (heavily modified). Configure command for gd: ./configure --with-png --with-freetype --with-jpeg Configure command for php: ./configure --enable-bcmath --enable-calendar --enable-ctype --enable-discard-path --enable-exif --enable-filepro --enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --enable-inline-optimization --enable-magic -quotes --enable-mbstr-enc-trans --enable-mbstring --enable-memory-limit --enable-safe-mode --enable-shmop --enable-sigchild --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp --with-jpeg-dir=/usr --with-mcrypt --with-mysql=/usr --with-png-dir=/usr --with-t1lib --with-tiff-dir=/usr --with-ttf --with-freetype-dir=yes --with-xml --with-zlib=yes --with-gd=/usr/local --with-openssl --with-curl --with-mm --with-dom-xslt --with-dom-exslt [2003-02-19 04:38:26] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-05 03:41:12] [EMAIL PROTECTED] What was the full configure line used? [2003-02-05 03:36:43] khin-shein dot khin at st dot com configure is pass with --with-gd but make is fail as per follow . Kindly advice asap. error--- Undefined first referenced symbol in file gdImageColorMatch ext/gd/gd.lo gdImageCreateFromGifext/gd/gd.lo gdImageRotate ext/gd/gd.lo gdImageCreateFromGifCtx ext/gd/gd.lo ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `sapi/cli/php' -- Edit this bug report at http://bugs.php.net/?id=22066&edit=1
#27238 [Opn]: iptcparse() function misses some fields
ID: 27238 Updated by: [EMAIL PROTECTED] Reported By: philip at nancarrow dot net Status: Open Bug Type: Feature/Change Request Operating System: Windows and Linux PHP Version: 4.3.4 New Comment: > I can provide you with JPEG files containing IIM record 1 > if required; they're quite common in the news industry. Please do :) If you can provide an URL with some images with the required fields and a txt file for the expected result. Note that I never read the charset part in any docs about IPTC standart. Have you a link that describes it? pierre Previous Comments: [2004-02-13 06:27:10] philip at nancarrow dot net Description: The iptcparse() function (GD extension) only returns IPTC/NAA records 2 and upward, skipping past record 1. This appears to be by design, but means that the returned data is incomplete, for example the "destination" dataset 1:05 is missing. Worse that this is the fact that "coded character set" (1:90) is missing, and without this value the encoding of the data is unknown (for example if 1:90 specifies ESC,%,G the data is UTF8 encoded). I assume that the current implementation is defaulting to ASCII or Latin1 encoding. I can provide you with JPEG files containing IIM record 1 if required; they're quite common in the news industry. Thank you -- Edit this bug report at http://bugs.php.net/?id=27238&edit=1
#22323 [Asn->Csd]: There's no way to output transparent truecolor PNG images
ID: 22323 Updated by: [EMAIL PROTECTED] Reported By: jukkaho at mail dot student dot oulu dot fi -Status: Assigned +Status: Closed Bug Type: GD related Operating System: Linux PHP Version: 4.3.0 Assigned To: pajoye New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. imagesavealpha has been added in cvs. The simple imagesavealpha wrapper is used. usage: thank's for your report pierre Previous Comments: [2003-02-20 23:49:14] jukkaho at mail dot student dot oulu dot fi I have submitted a proposed patch to the development mailing list (see http://marc.theaimsgroup.com/?l=php-dev&m=104577317709538&w=2). When everything's ok in cvs snapshot, this bug is closed. There's no state 'should be fixed in cvs' so this stays open. :) [2003-02-20 08:13:55] jukkaho at mail dot student dot oulu dot fi Relevant parts are not changed in CVS so there are still no way to call gdImageSaveAlpha() with a true argument so that alpha channel is actually sent to browser. Default value is still set to 0 and has the following comment: /* 2.0.2: alpha blending is now on by default, and saving of alpha is off by default. This allows font antialiasing to work as expected on the first try in JPEGs -- quite important -- and also allows for smaller PNGs when saving of alpha channel is not really desired, which it usually isn't! */ im->saveAlphaFlag = 0; In my case it really is desired. I want to be able to produce transparent PNGs. I just don't have access in PHP to change saveAlphaFlag value. Someone could just create a new PHP image function ImageSaveAlpha($im,$bool) that passes that info to gdImageSaveAlpha (gdImagePtr im, int saveAlphaArg); I have solved my blending problems already by using undocumented functions as I have described in bug #22327. [2003-02-20 07:30:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-02-20 04:24:57] jukkaho at mail dot student dot oulu dot fi Alpha channel in a truecolor image is only sent when im->saveAlphaFlag is true. It is by default set to false in gdImageCreateTrueColor() and there are no callers to gdImageSaveAlpha() to set it to any other value. I tested a hack where I call gdImageSaveAlpha() in PHP_FUNCTION(imagealphablending) and it worked mostly as expected. I'd guess that another function call is needed unless is it made to default behaviour and calls are embedded in PHP_FUNCTION(imagepng) etc. Only weird things that occured were that for some reason, target image alpha channel is discarded when blending other images to it. For example when blending fully transparent part over another fully transparent part resulted in a white area. White comes from destination image that's transparent too. Maybe I should open another bug for it? -- Edit this bug report at http://bugs.php.net/?id=22323&edit=1
#21560 [Ver]: imagettfbbox() returns different values in 4.3.0 and 4.2.1
ID: 21560 Updated by: [EMAIL PROTECTED] Reported By: ljpersson at hotmail dot com Status: Verified Bug Type: GD related Operating System: SusE 8.0 PHP Version: 4.3.1-dev -Assigned To: +Assigned To: pajoye New Comment: I confirm it too. I found where is the problem. I will try to fix it before the next release. Previous Comments: [2003-02-13 12:19:10] [EMAIL PROTECTED] Verified with latest CVS, this however appears to be an issue with the GD library itself since the problem is not particular to the bundled GD. [2003-02-13 11:45:01] [EMAIL PROTECTED] Please use the 'Edit submission' link when you reply to your _own_ report, otherwise the status remains at 'feedback'..and eventually gets automatically suspended. [2003-02-13 05:26:09] ljpersson at hotmail dot com Below is a simple test script that illustates the problem. You might need to change the path for the fonts to suit your setup. The script strokes a text and then draws the bounding box around the text. For angle = 0 the bounding box is correct but for any other angle it is off proportional to the angle. (With GD 2.01 this is correct but for higher versions the problem exists) /Johan 3 [1] => -1 [2] => 3 [3] => -154 [4] => -16 [5] => -154 [6] => -16 [7] => -2 ) PHP 4.2.3 With GD 2.08 gives [WRONG]: Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -153 [4] => -17 [5] => -153 [6] => -17 [7] => 13 ) PHP 4.3.0 With built-in GD gives [WRONG]: Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -153 [4] => -17 [5] => -153 [6] => -17 [7] => 13 ) PHP 4.3.1-dev (2002-02-07) [WRONG] Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -153 [4] => -17 [5] => -153 [6] => -17 [7] => 13 ) */ ?> [2003-02-09 02:41:22] [EMAIL PROTECTED] Hi, Can you provide a link with the test script and the font used ? thank's pierre [2003-02-07 10:03:02] ljpersson at hotmail dot com The problem still exists in snapshot 200302071430 for the _exact_ same text string imagettfbbox() (and the _exact_ same test script) returns the following (different) values depending on version of PHP and GD Snapshot 200302071430 Array ( [0] => -1 [1] => 14 [2] => -1 [3] => -226 [4] => -16 [5] => -226 [6] => -16 [7] => 14 ) PHP 4.3 (official release) Array ( [0] => -1 [1] => 13 [2] => -1 [3] => -226 [4] => -16 [5] => -226 [6] => -16 [7] => 13 ) PHP 4.2.3 (with GD 2.01) Array ( [0] => 3 [1] => -1 [2] => 3 [3] => -234 [4] => -16 [5] => -234 [6] => -16 [7] => -2 ) The only correct values are with GD 2.01 for both PHP 4.3 and snapshot the bounding box is incorrect since it starts 14 (in snapshot) or 13 (in 4.3) pixels in into the text. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21560 -- Edit this bug report at http://bugs.php.net/?id=21560&edit=1
#21524 [Asn->Csd]: Add imagesavealpha so that imagepng can output alpha channel
ID: 21524 Updated by: [EMAIL PROTECTED] Reported By: phpbugs at koimo dot net -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.0 Assigned To: pajoye New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-01-09 17:24:55] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Hello, This feature will be present in futur version of php (means not any upcoming bugfixes releases) using the bundled GD. Thank's for your report, pierre [2003-01-08 13:22:36] phpbugs at koimo dot net (Not sure whether this should be here or under GD related) It would be useful if PHP had access to the gdSaveAlpha function in the GD library. Using PHP 4.3.0 with bundled GD, there is currently no way I can see to prevent imagepng stripping the alpha channel of a truecolor image. The following script produces a white circle on a black background, rather than a semi-transparent circular 'hole': According to the GD change list at http://www.boutell.com/gd/manual2.0.9.html#whatsnew2.0.2 this is the correct default behaviour since version 2.0.2 - there is a function gdSaveAlpha to turn on and off alpha output which appears to be present in the bundled GD in CVS but at the moment without any PHP wrapper. A PHP function imagesavealpha(resource image, bool savealpha) would allow alpha output when required without breaking any existing scripts. -S. Haydon -- Edit this bug report at http://bugs.php.net/?id=21524&edit=1
#22646 [Opn->Csd]: image functions with 4 params (imagegd2) never write to files
ID: 22646 Updated by: [EMAIL PROTECTED] Reported By: swbrown at ucsd dot edu -Status: Open +Status: Closed Bug Type: GD related Operating System: any PHP Version: 4.3.1 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2003-03-11 21:30:20] swbrown at ucsd dot edu If four args are specified to an image function, like imagegd2, php would previously never write to a file due to a bug. This fixes it to work like three argument functions. Patch (this needs to be applied to both php4 and php5 head): http://www-cse.ucsd.edu/~sbrown/patches/php-4.3.1-gd-four-param-bug-swb.patch (Note that bug #22645 will prevent even reaching this bug in the php4 branch atm.) -- Edit this bug report at http://bugs.php.net/?id=22646&edit=1
#21560 [Asn->Sus]: imagettfbbox() returns different values in 4.3.0 and 4.2.1
ID: 21560 Updated by: [EMAIL PROTECTED] Reported By: ljpersson at hotmail dot com -Status: Assigned +Status: Suspended Bug Type: GD related Operating System: SusE 8.0,SuSE 8.2 PHP Version: 4.3.1-dev, 4.3.2RC2, 4.3.2RC3 Assigned To: pajoye Previous Comments: [2003-05-16 19:37:07] ljpersson at hotmail dot com Just checked with 4.3.2RC3 and the problem still exists. [2003-05-05 13:23:02] ljpersson at hotmail dot com This problem still exists in 4.3.2RC2. This returns yet another set of (wrong) coordinates for the bounding box. With 4.3.2RC2 (Compiled on SuSE 8.2) gives the following wrong return array: Array ( [0] => -1 [1] => 14 [2] => -1 [3] => -146 [4] => -17 [5] => -146 [6] => -17 [7] => 14 ) Which is again different from what was returned in 4.3.1 [2003-02-27 08:47:02] [EMAIL PROTECTED] don't forget.. :) [2003-02-26 19:55:33] [EMAIL PROTECTED] I confirm it too. I found where is the problem. I will try to fix it before the next release. [2003-02-13 12:19:10] [EMAIL PROTECTED] Verified with latest CVS, this however appears to be an issue with the GD library itself since the problem is not particular to the bundled GD. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21560 -- Edit this bug report at http://bugs.php.net/?id=21560&edit=1
#24075 [Opn]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions
ID: 24075 Updated by: [EMAIL PROTECTED] Reported By: Sven dot Schnitzke at t-online dot de Status: Open -Bug Type: PEAR related +Bug Type: *General Issues Operating System: WIN98SE PHP Version: 4.3.2 New Comment: It tries to detect the current SAPI. Why do you use a pif do launch php? Then I do not know what is related with PEAR if php launched with a pif does not find some dlls. Comments? btw, have you think about moving to real OS? like something newer than win98se? win2K? pierre Previous Comments: [2003-06-09 08:18:15] [EMAIL PROTECTED] I've no idea what PHP 4.4-dev is..last release is 4.3.2.. Reclassified as pear bug. [2003-06-09 03:36:18] Sven dot Schnitzke at t-online dot de (IMHO the reason for this trouble is that relative extension dir spec is based upon cwd whereas it should be based upon the folder php resides in). Sorry, the problem was in go-pear.php. It tries to invoke php.exe -v to learn something of the returned string. With my inst the cli version of php is supposed to be invoked via PIF and cannot be launched directly via exec. It was this 'inner' call that issued the complaints about the missing dlls. Obviously with absolute path spec this call finds the extensions and everything is fine. Still don't know why e.g. a PHP4.4-dev (feb03 approx) works with relative specs? [2003-06-07 11:25:04] Sven dot Schnitzke at t-online dot de Yes, I am 100% sure. Meanwhile I verified that an absolute path spec does work. It is _really_ strange: curiously I tried go_pear.php and I encounter the named problem. When executing other scripts this is not the case. There is another strange thing about go_pear.php: it thinks I am using cgi while I am using php4apache. I tried go_pear with a PHP 4.4-dev and it worked (with some minor gliches) !?!? I will investigate further. It seems it could be a pear issue. [2003-06-07 04:50:23] [EMAIL PROTECTED] Are you 100% sure you have really updated PHP and that you don't have duplicate php4ts.dll's in your system? And that the one you have is for PHP 4.3.2? And FYI: earlier extensions might not work with current php. [2003-06-07 03:49:11] Sven dot Schnitzke at t-online dot de I just downloaded PHP-4.3.2 final and wanted to install it. (extension dir is specified as ..\php\extensions) I have parallel folders with some versions of PHP4 from 4.0.6 thru 4.3.2-RC and some snapshot 4.4-dev which I arranged to have at hand by just copying PHP.INI to the Apache folder and renaming the PHP folder to be the one supposed to hold the active PHP. No parts of PHP outside these folders except some two PIFS used to start PHP from the command line. This works because the Apache folder and the active PHP folder are parallel in the same tree. All versions I have work well this way including an earlier 4.3.2-RC. Now 4.3.2 final does not! IMHO copying the extensions to the WINSYS folder is not a viable way because a) it clutters WINSYS b) you are unable to quickly go forth (and back in case of trouble) with upgrading PHP Maybe absolute path works but I don't think it is a good idea to have a lot of places where absolute path specs are required. -- Edit this bug report at http://bugs.php.net/?id=24075&edit=1
#32803 [Opn->Asn]: GD-Functions update
ID: 32803 Updated by: [EMAIL PROTECTED] Reported By: peter at dmx-network dot com -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: Linux (Fedora C3) -PHP Version: 4.3.11 +PHP Version: 5.x -Assigned To: +Assigned To: pajoye New Comment: Definitivally never in 4.3.x, I will do it in HEAD in the next weeks (as well as some other new things). --Pierre Previous Comments: [2005-04-23 14:25:42] peter at dmx-network dot com Description: Please upgrade the GD-Functions with the new animated gif support.. Thanks! -- Edit this bug report at http://bugs.php.net/?id=32803&edit=1
#32893 [Opn->Fbk]: imagettftext crash
ID: 32893
Updated by: [EMAIL PROTECTED]
Reported By: php at fiddaman dot net
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Solaris 9
PHP Version: 4.3.11
-Assigned To:
+Assigned To: pajoye
New Comment:
Which Freetype version do you use?
Please give us a link to the TTF file you use.
Previous Comments:
[2005-04-30 13:53:31] php at fiddaman dot net
Same result with the snapshot:
Starting program:
/spool/src/build/php4-STABLE-200504301042/sapi/cli/php t
Program received signal SIGSEGV, Segmentation fault.
0x0001001a6df4 in zend_parse_va_args (num_args=4,
type_spec=0x10023d1b3 "lllss|a", va=0x7fffe978, flags=0)
at /spool/src/build/php4-STABLE-200504301042/Zend/zend_API.c:260
260 *p =
Z_LVAL_PP(arg);
it looks like a memory alignment problem, the SPARC MMU won't allow a
32 or 64-bit read that isn't aligned.
I added this just before line 260:
zend_printf("Alignment: %d\n", __alignof__(arg));
which gives:
% sapi/cli/php t
Alignment: 8
zsh: bus error (core dumped) sapi/cli/php t
[2005-04-30 03:45:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I can't reproduce this crash.
[2005-04-29 21:26:27] php at fiddaman dot net
Description:
PHP crashes in imagettftext - worked fine in 4.3.10
./configure \
--prefix=/opt/php \
--with-exec-dir=/opt/php/bin \
--with-apxs2=/opt/apache/bin/apxs \
--enable-memory-limit \
--with-iconv \
--enable-ftp \
--enable-mbstring \
--with-mbstring=all \
--with-gettext \
--enable-calendar \
--with-mime-magic \
--with-mysql \
--with-mysqli=/opt/mysql/bin/mysql_config \
\
--with-openssl=/opt/openssl \
--with-mysql=/opt/mysql \
--with-gdbm=/opt/GNUgdbm \
--with-db4=/opt/newdb \
--with-dom=/opt/libxml2 \
--with-gmp=/opt/GNUmp \
--with-mcrypt=/opt/libmcrypt \
\
--with-imap=/opt/c-client \
--with-imap-ssl=/opt/openssl \
\
--with-zlib=/usr \
--with-zlib-dir=/usr \
--with-bz2=/usr \
\
--with-gd \
--with-jpeg-dir=/opt/libjpg \
--with-png-dir=/opt/libpng \
--with-freetype-dir=/opt/freetype
Reproduce code:
---
Expected result:
No errors.
Actual result:
--
#0 0x0001001a70b4 in zend_parse_va_args (num_args=4,
type_spec=0x10023cd7b "lllss|a", va=0x7fffe898, flags=0)
at /spool/src/build/php-4.3.11/Zend/zend_API.c:260
#1 0x0001001a7b18 in zend_parse_parameters (num_args=8,
type_spec=0x10023cd78 "rddlllss|a")
at /spool/src/build/php-4.3.11/Zend/zend_API.c:552
#2 0x000100071a7c in php_imagettftext_common (ht=8,
return_value=0x10061dd28, this_ptr=0x0, return_value_used=0,
mode=0,
extended=0) at /spool/src/build/php-4.3.11/ext/gd/gd.c:3042
#3 0x0001001bb0c4 in execute (op_array=0x10063b2a8)
at /spool/src/build/php-4.3.11/Zend/zend_execute.c:1654
#4 0x0001001a64b0 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /spool/src/build/php-4.3.11/Zend/zend.c:926
#5 0x000100173ba0 in php_execute_script
(primary_file=0x7aa0)
at /spool/src/build/php-4.3.11/main/main.c:1745
#6 0x0001001c3f08 in main (argc=2, argv=0x7b98)
at /spool/src/build/php-4.3.11/sapi/cli/php_cli.c:828
--
Edit this bug report at http://bugs.php.net/?id=32893&edit=1
#32891 [Ver->Csd]: Bug using imagefilledellipse at position 0 vertically
ID: 32891
Updated by: [EMAIL PROTECTED]
Reported By: anders at apt dot no
-Status: Verified
+Status: Closed
Bug Type: GD related
Operating System: *
PHP Version: 4CVS, 5.*CVS (2005-04-30)
Assigned To: pajoye
New Comment:
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.
Fixed in php4, 5.0 and 5.
Thanks for the test case
--Pierre
Previous Comments:
[2005-04-29 14:04:15] anders at apt dot no
Description:
While drawing an elliptic object positioned vertically at the top(0px)
the second line is not drawn. I'm using the embedded GD library (2.0.28
compatible).
Reproduce code:
---
if ($im = @imagecreatetruecolor(100, 100)) {
$intCol = imagecolorallocate($im, 0xFF, 0x02, 0xF0);
imagefilledellipse($im, 50, 0, 50, 50, $intCol);
header('Content-type: image/png');
imagepng($im);
} else {
echo 'Could not create truecolor image';
}
Expected result:
I expect to see half a circle, with it's center at 50 x 0, like this:
http://kunde.apt.no/aso/imagefilledellipse/imagefilledellipse_expected_result.png
Actual result:
--
Instead I get this circle, with one line missing:
http://kunde.apt.no/aso/imagefilledellipse/imagefilledellipse_actual_result.png
This image was created with the reproduce code:
http://kunde.apt.no/aso/imagefilledellipse/imagefilledellipse_bug.php
--
Edit this bug report at http://bugs.php.net/?id=32891&edit=1
#32893 [Opn->Csd]: imagettftext crash
ID: 32893
Updated by: [EMAIL PROTECTED]
Reported By: php at fiddaman dot net
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: Solaris 9
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
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.
PHP4 Branch was not synced with head.
Thanks for the notice
--Pierre
Previous Comments:
[2005-05-01 13:59:26] php at fiddaman dot net
Here's a patch which fixes the problem. The variable being passed to
the zend argument parser was too small to hold the result (int versus
long).
--- ext/gd/gd.c~2005-05-01 11:36:21.134419000 +
+++ ext/gd/gd.c 2005-05-01 11:42:37.369849000 +
@@ -3017,7 +3017,8 @@
{
zval *IM, *EXT = NULL;
gdImagePtr im=NULL;
- int col = -1, x = -1, y = -1, str_len, fontname_len, i,
brect[8];
+ long col = -1, x = -1, y = -1;
+ int str_len, fontname_len, i, brect[8];
double ptsize, angle;
unsigned char *str = NULL, *fontname = NULL;
char *error = NULL;
I'm using freetype 2.1.3 and gd 2.0.15 but it wasn't getting to even
call a function in those libraries.
A simpler test case which doesn't need the font file. It generates an
error in 4.3.10 but still crashes the snapshot.
% cat test
% ./php4-STABLE-200504301042/sapi/cli/php test
zsh: bus error (core dumped) ./php4-STABLE-200504301042/sapi/cli/php
test
% ./php-4.3.10/sapi/cli/php test
PHP Warning: imagettftext(): Could not read font in
/spool/src/build/test on line 3
[2005-05-01 01:29:04] [EMAIL PROTECTED]
Which Freetype version do you use?
Please give us a link to the TTF file you use.
[2005-04-30 13:53:31] php at fiddaman dot net
Same result with the snapshot:
Starting program:
/spool/src/build/php4-STABLE-200504301042/sapi/cli/php t
Program received signal SIGSEGV, Segmentation fault.
0x0001001a6df4 in zend_parse_va_args (num_args=4,
type_spec=0x10023d1b3 "lllss|a", va=0x7fffe978, flags=0)
at /spool/src/build/php4-STABLE-200504301042/Zend/zend_API.c:260
260 *p =
Z_LVAL_PP(arg);
it looks like a memory alignment problem, the SPARC MMU won't allow a
32 or 64-bit read that isn't aligned.
I added this just before line 260:
zend_printf("Alignment: %d\n", __alignof__(arg));
which gives:
% sapi/cli/php t
Alignment: 8
zsh: bus error (core dumped) sapi/cli/php t
[2005-04-30 03:45:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
I can't reproduce this crash.
[2005-04-29 21:26:27] php at fiddaman dot net
Description:
PHP crashes in imagettftext - worked fine in 4.3.10
./configure \
--prefix=/opt/php \
--with-exec-dir=/opt/php/bin \
--with-apxs2=/opt/apache/bin/apxs \
--enable-memory-limit \
--with-iconv \
--enable-ftp \
--enable-mbstring \
--with-mbstring=all \
--with-gettext \
--enable-calendar \
--with-mime-magic \
--with-mysql \
--with-mysqli=/opt/mysql/bin/mysql_config \
\
--with-openssl=/opt/openssl \
--with-mysql=/opt/mysql \
--with-gdbm=/opt/GNUgdbm \
--with-db4=/opt/newdb \
--with-dom=/opt/libxml2 \
--with-gmp=/opt/GNUmp \
--with-mcrypt=/opt/libmcrypt \
\
--with-imap=/opt/c-client \
--with-imap-ssl=/opt/openssl \
\
--with-zlib=/usr \
--with-zlib-dir=/usr \
--with-bz2=/usr \
\
--with-gd \
--with-jpeg-dir=/opt/libjpg \
--with-png-dir=/opt/libpng \
--with-freetype-dir=/opt/freetype
Reproduce code:
---
Expected result:
No errors.
Actual result:
--
#0 0x0001001a70b4 in zend_parse_va_args (num_args=4,
type_spec=0x10023cd7b "lllss|a", va=0x7fffe898, flags=0)
at /spool/src/build/php-4.3.11/Ze
#32921 [Fbk]: ImageRotate() lost of alphalayer
ID: 32921 Updated by: [EMAIL PROTECTED] Reported By: eckounlimited at gmx dot nnet Status: Feedback Bug Type: GD related Operating System: * PHP Version: 5CVS-2005-05-02 (dev) -Assigned To: +Assigned To: pajoye New Comment: Hi, Partially fixed in CVS, will commit asap the definitive fix, keeping BC. --Pierre Previous Comments: [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
#33162 [Fbk]: imagecreatefromstring segfaults
ID: 33162
Updated by: [EMAIL PROTECTED]
Reported By: julien at synten dot com
Status: Feedback
Bug Type: Reproducible crash
Operating System: Linux 2.4.29
PHP Version: 4.3.11
-Assigned To:
+Assigned To: pajoye
New Comment:
Cannot reproduce.
You certainly use an external GD and not the bundled version.
Please try using the bundled version ("./configure --with-gd").
--Pierre
Previous Comments:
[2005-05-27 13:58:55] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2005-05-27 13:06:32] julien at synten dot com
Description:
imagecreatefromstring seems to segfault when a a bogus string with
letters is provided, works when this string is only non-char.
Reproduce code:
---
27/05 12:15 [EMAIL PROTECTED] /home/julien/www# php
Warning: imagecreatefromstring()
[http://www.php.net/function.imagecreatefromstring]: Data is not in a
recognized format. in - on line 3
OK 10
27/05 12:15 [EMAIL PROTECTED] /home/julien/www# php
zsh: segmentation fault php
27/05 12:15 [EMAIL PROTECTED] /home/julien/www# php
Warning: imagecreatefromstring()
[http://www.php.net/function.imagecreatefromstring]: Data is not in a
recognized format. in - on line 3
OK 10
27/05 12:15 [EMAIL PROTECTED] /home/julien/www# php
zsh: segmentation fault php
27/05 12:15 [EMAIL PROTECTED] /home/julien/www# php
Warning: imagecreatefromstring()
[http://www.php.net/function.imagecreatefromstring]: Data is not in a
recognized format. in - on line 3
OK 10
27/05 12:16 [EMAIL PROTECTED] /home/julien/www# php
zsh: segmentation fault php
Expected result:
No segfaults, just warnings.
Actual result:
--
Segfaults.
--
Edit this bug report at http://bugs.php.net/?id=33162&edit=1
#33196 [Opn->Bgs]: cannot display JPEG from oracle db using oci8
ID: 33196
Updated by: [EMAIL PROTECTED]
Reported By: tommy dot yan at hp dot com
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: windows2000
PHP Version: 4.3.9
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Do not print out any chararter while trying to display an image.
Previous Comments:
[2005-05-31 05:27:33] tommy dot yan at hp dot com
Description:
cannot display the picture uploaded, only a 'cross' sign displayed.
I use apache 2.0.54, php 4.3.6, win2k, oracle 10g, ado 4.11.
Reproduce code:
---
mainly part is here:
Execute("SELECT BLOBDATA FROM BTAB WHERE BLOBID =".$id);
print "id=".$id;
header("Content-type: image/JPEG");
$row = $rs->FetchRow();
print $row[0];
?>
PLEASE SEE
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=233174&message=664237#664237
BOTTOM MESSAGE.
Expected result:
jpeg display normally
Actual result:
--
a 'cross sign' is displayed. if SQL debugging is enabled, a lot of
wrong character is displayed.
--
Edit this bug report at http://bugs.php.net/?id=33196&edit=1
#33404 [Fbk]: imagettftext doesn't work
ID: 33404 Updated by: [EMAIL PROTECTED] Reported By: david dot perianghendra at gmail dot com Status: Feedback Bug Type: GD related Operating System: Linux PHP Version: 5.0.3 -Assigned To: +Assigned To: pajoye New Comment: Please provide a link to your TTF font. But it works well here (using windows cour.ttf or any other valid ttf). --Pierre Previous Comments: [2005-06-20 09:31:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip AFAIK, this was fixed long time ago. [2005-06-20 09:18:27] david dot perianghendra at gmail dot com Description: I use PHPv5.0.3,Freetype v1.4, GD2 Library v2.0.28 I use imagettftext in my script with font file reside in the same directory, but it seems that it doens't work though i have tried to set 'GDFONTPATH' environtment variable. The result is always the same. The resulting image doesn't contain the text with specified TTF and no error occured. Reproduce code: --- Expected result: The image should contain image with text written on it with specified TTF. Actual result: -- Image without the text with specified TTF. -- Edit this bug report at http://bugs.php.net/?id=33404&edit=1
#33404 [Opn->Fbk]: imagettftext doesn't work
ID: 33404 Updated by: [EMAIL PROTECTED] Reported By: david dot perianghendra at gmail dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Linux PHP Version: 5.0.3 Assigned To: pajoye New Comment: We need the TTF file, provide a link where we can dowload it. I still have no idea what your result is, provide a link to the result image as well. iirc, links could something like http://youdomainhere.com/cour.ttf or http://youdomainhere.com/result_img.png Previous Comments: [2005-06-21 09:36:54] david dot perianghendra at gmail dot com I have add the full path link to my ttf font file but it's still produce the same result. [2005-06-21 09:07:21] [EMAIL PROTECTED] Please provide a link to your TTF font. But it works well here (using windows cour.ttf or any other valid ttf). --Pierre [2005-06-20 09:31:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip AFAIK, this was fixed long time ago. [2005-06-20 09:18:27] david dot perianghendra at gmail dot com Description: I use PHPv5.0.3,Freetype v1.4, GD2 Library v2.0.28 I use imagettftext in my script with font file reside in the same directory, but it seems that it doens't work though i have tried to set 'GDFONTPATH' environtment variable. The result is always the same. The resulting image doesn't contain the text with specified TTF and no error occured. Reproduce code: --- Expected result: The image should contain image with text written on it with specified TTF. Actual result: -- Image without the text with specified TTF. -- Edit this bug report at http://bugs.php.net/?id=33404&edit=1
#33404 [Csd->Bgs]: imagettftext doesn't work
ID: 33404 Updated by: [EMAIL PROTECTED] Reported By: david dot perianghendra at gmail dot com -Status: Closed +Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 5.0.3 Assigned To: pajoye New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Works here using your font. You may have another problem in your script, tip of the day: E_ALL --Pierre Previous Comments: [2005-06-21 12:55:24] [EMAIL PROTECTED] This is why you should *always* use the bundled GD library! [2005-06-21 12:44:01] david dot perianghendra at gmail dot com Thxs [2005-06-21 12:42:50] david dot perianghendra at gmail dot com Here come the bad news... - I finally managed to ugrade my GD library (from 1.8.4 => 2.0.33) and compile it into php. The good news is - It works. Resulting image contain text with specified TTF. I'm sorry be4 n thxs [2005-06-21 12:37:21] [EMAIL PROTECTED] This works fine for me: Your font-filename is in lowercase, I hope you knew that.. :) And I'm using the PHP's bundled GD, and freetype 2.1.9 [2005-06-21 10:32:07] david dot perianghendra at gmail dot com http://bilbo.kgblogger.com/testing/cour.ttf The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33404 -- Edit this bug report at http://bugs.php.net/?id=33404&edit=1
#33467 [Opn->Bgs]: ImageCreate function now acts oddly - WHY?
ID: 33467 Updated by: [EMAIL PROTECTED] Reported By: m02041952 at yahoo dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: win98 PHP Version: 5.0.4 -Assigned To: +Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php We did not destroy anything. Both exists. Previous Comments: [2005-06-24 17:17:57] m02041952 at yahoo dot com Description: I feel unhappy because 'enhancements' performed from ImageCreate to ImageCreateTrueColor. Now I have problems that appears to be impossible of solving. I was obligued to move to ICtrueColor because my pictures suddenly lost all its colors from day to night. In desperation I discovered that some genious had 'increased' GD functions. First at all, have you measured file size of your ImageCreateTrueColor 'thumbnails'? . Ok, for me they increased from 2 or 3 Kb (previous ImageCreate) to some 15 to 20 Kb each one (new ImageCreateTrueColor function), so my 'thumbnails albums' which should show some 25-50 tiny pictures in a flash, became unavailable for non-adsl users. I remember old fashioned days when my album opened thumbnails like pop-corns, all of them whth perfect colors. Second, I have zoom commands on these thumbnails. Previously zoom worked fine with ImageCreate because it performed task of reducing kb traffic between server and client, but with ImageCreateTrueColor now this traffic has INCREASED, because a true color image transmit several times more bits than even original image stored in server. Third, now I can't any more produce thumbnails of images from some sizes. I am still trying to figure out what the hell this problem could be, but with previous ImageCreate function images of 1200 x 1300 or so was created instantly with no problem. Now browser just shows users an 'incorrect image' icon instead. I don't know where the problem is, my images have not changed at all. I want to say to people who develops GD that many (maybe ten thousands) users probably use these functions in their albums, then you can't just change functions performance / behaviour and say 'hi, use this new command instead now' with no previous analisys of performance and impact on actual systems. The correct way of making these changes is by letting untouched functions that are well stablished in the market (like previous imagecreate) and to develop new ones. Why you destroyed old ImageCreate to make the new function ImageCreateTrueColor? . I can't understand this Thanks very much for your attention. Miguel - Brazil Jun 2005. -- Edit this bug report at http://bugs.php.net/?id=33467&edit=1
#33590 [Opn->Fbk]: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error
ID: 33590 Updated by: [EMAIL PROTECTED] Reported By: jeck at kntel dot kiev dot ua -Status: Open +Status: Feedback Bug Type: GD related Operating System: FreeBSD 5.4-RELEASE PHP Version: 4.3.11 -Assigned To: +Assigned To: pajoye New Comment: Please give us one image that causes this problem. Copy a link to it here. --Pierre Previous Comments: [2005-07-06 15:38:21] jeck at kntel dot kiev dot ua Description: Hi, just trying to copy images from one server to other but resize them. I try to grab them using imagecreatefromjpeg(HTTP_IMG_URL), but somehow got an error line like this "Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error"... One more thing - i trying to resize not one picture but ~65000 in a loop, maybe this fact has importance... Reproduce code: --- //... some calculation code $img_src = imagecreatefromjpeg($http_img_url); $img_dst = imagecreatetruecolor(100, 100); // $start_x, $start_y, $width, $height, $iwidth, $height - // calculated above imagecopyresampled($img_dst, $img_src, $start_x, $start_y, 0, 0, $width, $height, $iwidth, $height); imagejpeg($img_dst, $g_dstfile); imagedestroy($img_dst); // ... some insignificant code, and of function Expected result: just resized copy of image -- Edit this bug report at http://bugs.php.net/?id=33590&edit=1
#33590 [Opn->Bgs]: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error
ID: 33590 Updated by: [EMAIL PROTECTED] Reported By: jeck at kntel dot kiev dot ua -Status: Open +Status: Bogus Bug Type: GD related Operating System: FreeBSD 5.4-RELEASE PHP Version: 4.3.11 Assigned To: pajoye New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. This image works here. If you are really trying to resize 65000 images in one shot, you may consider other solutions. This is the worst thing to do. If you have other images which failed to be open with imagejpeg, please provide them here and put this bug back to open. --Pierre Previous Comments: [2005-07-06 15:53:26] jeck at kntel dot kiev dot ua http://www.ix.nu/data/filestorage/gallery/49/49IkarlekYC.jpg //sorry about content of this image, but this is it... [2005-07-06 15:48:28] [EMAIL PROTECTED] Please give us one image that causes this problem. Copy a link to it here. --Pierre [2005-07-06 15:38:21] jeck at kntel dot kiev dot ua Description: Hi, just trying to copy images from one server to other but resize them. I try to grab them using imagecreatefromjpeg(HTTP_IMG_URL), but somehow got an error line like this "Warning: imagecreatefromjpeg(): gd-jpeg: JPEG library reports unrecoverable error"... One more thing - i trying to resize not one picture but ~65000 in a loop, maybe this fact has importance... Reproduce code: --- //... some calculation code $img_src = imagecreatefromjpeg($http_img_url); $img_dst = imagecreatetruecolor(100, 100); // $start_x, $start_y, $width, $height, $iwidth, $height - // calculated above imagecopyresampled($img_dst, $img_src, $start_x, $start_y, 0, 0, $width, $height, $iwidth, $height); imagejpeg($img_dst, $g_dstfile); imagedestroy($img_dst); // ... some insignificant code, and of function Expected result: just resized copy of image -- Edit this bug report at http://bugs.php.net/?id=33590&edit=1
#33593 [Opn->Bgs]: phpinfo() reports version 4.3.10 using CLI or php4apache2.dll
ID: 33593 Updated by: [EMAIL PROTECTED] Reported By: eddie at g3 dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: Windows XP SP2 PHP Version: 4.3.11 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You have to re build and install each SAPI (cli, (f)cgi, apache1, 2...). Previous Comments: [2005-07-06 23:09:58] eddie at g3 dot com Description: When using phpinfo() in a script under PHP 4.3.11 and Apache 2.0.52 using php4apache2.dll, the version reports as 4.3.10. Using the CLI version of php.exe does as well. However the CGI version correctly reports 4.3.11. Lookding at the build dates, it appears that the CLI and dll were not rebuilt. PHP was installed from php-4.3.11-Win32.zip. Using an untouched php.ini-recommended for my php.ini. -- Edit this bug report at http://bugs.php.net/?id=33593&edit=1
#33599 [Opn->Fbk]: poor quality imagettftext
ID: 33599
Updated by: [EMAIL PROTECTED]
Reported By: kni at exactal dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: FreeBSD
PHP Version: 4.3.11
-Assigned To:
+Assigned To: pajoye
New Comment:
Please use the bundled library ("configure --with-gd"). Take care to do
not have the developement package of the system GD installed or
available while configuring and installing.
Which Freetype version do you have?
--Pierre
Previous Comments:
[2005-07-07 05:18:33] kni at exactal dot com
Looks like someone else is experiencing a similar problem --
Comment from: http://www.php.net/imagettftext
gerritvg at gmail dot com
20-May-2005 05:24
The ImageTTFText() function alway work correct. Until the've installed
GD version 2.0.23 on the server.
The quality of the generated buttons is much lower.
[2005-07-07 05:10:47] kni at exactal dot com
Description:
On my local Linux environment (running PHP 4.3.4 / GD bundled (2.0.15
compatible)) -- all is well. My script produces the following image:
http://www.exactal.com/tmp/phpbugs/wrap-local.png
In my live FreeBSD environment (running PHP 4.3.11 / GD bundled (2.0.28
compatible)) -- output from the same script is of lower quality:
http://www.exactal.com/tmp/phpbugs/wrap-remote.png
Note in particular poor character widths and character spacing (note
also that imagettfbbox used to assess the type width returns a value
that results in the type being truncated).
This is reproducable with different font files, sizes, etc, and is more
noticeable with smaller font sizes.
Reproduce code:
---
$bbox[6])?$bbox[6]:$bbox[0]; // determine most far
points
$right=($bbox[2]>$bbox[4])?$bbox[2]:$bbox[4];
$width=$right-$left+$margin; // get total width
$newImg = ImageCreateTrueColor($width,30);
$background = imagecolorallocate($newImg, 255, 255, 255);
ImageFill($newImg, 1, 1, $background);
$foreground = imagecolorallocate($newImg, 0, 0, 0);
imagettftext($newImg, $font_size, 0, 0, 20, $foreground, $font,
$text);
header("Content-type: image/png");
ImagePNG($newImg);
ImageDestroy($newImg);
?>
Expected result:
http://www.exactal.com/tmp/phpbugs/wrap-local.png
Actual result:
--
http://www.exactal.com/tmp/phpbugs/wrap-remote.png
--
Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn]: poor quality imagettftext
ID: 33599
Updated by: [EMAIL PROTECTED]
Reported By: kni at exactal dot com
Status: Open
Bug Type: GD related
Operating System: FreeBSD
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
Do you have a link to the TTF font you use?
Check your ports to see which Freetype version.
--Pierre
Previous Comments:
[2005-07-07 08:32:32] kni at exactal dot com
Locally I'm running freetype-2.1.8
[2005-07-07 08:27:22] kni at exactal dot com
I didn't configure the live env myself (only the dev. env, which, alas,
works). How does one work out which freetype version is running? Sorry
for sounding like a goof! Perhaps this can help you --
http://d144091.tmp56.quadrahosting.com/phpinfo.php
[2005-07-07 08:14:27] [EMAIL PROTECTED]
Please use the bundled library ("configure --with-gd"). Take care to do
not have the developement package of the system GD installed or
available while configuring and installing.
Which Freetype version do you have?
--Pierre
[2005-07-07 05:18:33] kni at exactal dot com
Looks like someone else is experiencing a similar problem --
Comment from: http://www.php.net/imagettftext
gerritvg at gmail dot com
20-May-2005 05:24
The ImageTTFText() function alway work correct. Until the've installed
GD version 2.0.23 on the server.
The quality of the generated buttons is much lower.
[2005-07-07 05:10:47] kni at exactal dot com
Description:
On my local Linux environment (running PHP 4.3.4 / GD bundled (2.0.15
compatible)) -- all is well. My script produces the following image:
http://www.exactal.com/tmp/phpbugs/wrap-local.png
In my live FreeBSD environment (running PHP 4.3.11 / GD bundled (2.0.28
compatible)) -- output from the same script is of lower quality:
http://www.exactal.com/tmp/phpbugs/wrap-remote.png
Note in particular poor character widths and character spacing (note
also that imagettfbbox used to assess the type width returns a value
that results in the type being truncated).
This is reproducable with different font files, sizes, etc, and is more
noticeable with smaller font sizes.
Reproduce code:
---
$bbox[6])?$bbox[6]:$bbox[0]; // determine most far
points
$right=($bbox[2]>$bbox[4])?$bbox[2]:$bbox[4];
$width=$right-$left+$margin; // get total width
$newImg = ImageCreateTrueColor($width,30);
$background = imagecolorallocate($newImg, 255, 255, 255);
ImageFill($newImg, 1, 1, $background);
$foreground = imagecolorallocate($newImg, 0, 0, 0);
imagettftext($newImg, $font_size, 0, 0, 20, $foreground, $font,
$text);
header("Content-type: image/png");
ImagePNG($newImg);
ImageDestroy($newImg);
?>
Expected result:
http://www.exactal.com/tmp/phpbugs/wrap-local.png
Actual result:
--
http://www.exactal.com/tmp/phpbugs/wrap-remote.png
--
Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn->Fbk]: poor quality imagettftext
ID: 33599
Updated by: [EMAIL PROTECTED]
Reported By: kni at exactal dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: FreeBSD
PHP Version: 4.3.11
Assigned To: pajoye
Previous Comments:
[2005-07-07 08:34:09] [EMAIL PROTECTED]
Do you have a link to the TTF font you use?
Check your ports to see which Freetype version.
--Pierre
[2005-07-07 08:32:32] kni at exactal dot com
Locally I'm running freetype-2.1.8
[2005-07-07 08:27:22] kni at exactal dot com
I didn't configure the live env myself (only the dev. env, which, alas,
works). How does one work out which freetype version is running? Sorry
for sounding like a goof! Perhaps this can help you --
http://d144091.tmp56.quadrahosting.com/phpinfo.php
[2005-07-07 08:14:27] [EMAIL PROTECTED]
Please use the bundled library ("configure --with-gd"). Take care to do
not have the developement package of the system GD installed or
available while configuring and installing.
Which Freetype version do you have?
--Pierre
[2005-07-07 05:18:33] kni at exactal dot com
Looks like someone else is experiencing a similar problem --
Comment from: http://www.php.net/imagettftext
gerritvg at gmail dot com
20-May-2005 05:24
The ImageTTFText() function alway work correct. Until the've installed
GD version 2.0.23 on the server.
The quality of the generated buttons is much lower.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33599
--
Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn->Fbk]: poor quality imagettftext
ID: 33599
Updated by: [EMAIL PROTECTED]
Reported By: kni at exactal dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: FreeBSD
PHP Version: 4.3.11
Assigned To: pajoye
New Comment:
I just checked your phpinfo. It sounds like you have an old FT version,
probably version 1. Please check that and update the freetype lib to a
more recent (and decent) version if needed.
--Pierre
Previous Comments:
[2005-07-07 08:37:43] kni at exactal dot com
http://d144091.tmp56.quadrahosting.com/resources/zapf.ttf
I've tested it and reproduced the same problem with other fonts also.
eg.
http://d144091.tmp56.quadrahosting.com/resources/GNMI.TTF
[2005-07-07 08:34:09] [EMAIL PROTECTED]
Do you have a link to the TTF font you use?
Check your ports to see which Freetype version.
--Pierre
[2005-07-07 08:32:32] kni at exactal dot com
Locally I'm running freetype-2.1.8
[2005-07-07 08:27:22] kni at exactal dot com
I didn't configure the live env myself (only the dev. env, which, alas,
works). How does one work out which freetype version is running? Sorry
for sounding like a goof! Perhaps this can help you --
http://d144091.tmp56.quadrahosting.com/phpinfo.php
[2005-07-07 08:14:27] [EMAIL PROTECTED]
Please use the bundled library ("configure --with-gd"). Take care to do
not have the developement package of the system GD installed or
available while configuring and installing.
Which Freetype version do you have?
--Pierre
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33599
--
Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn->Fbk]: poor quality imagettftext
ID: 33599 Updated by: [EMAIL PROTECTED] Reported By: kni at exactal dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: FreeBSD PHP Version: 4.3.11 Assigned To: pajoye New Comment: '--with-ttf' This is freetype 1.0 support. You activated both, it's no good idea. I have the feelings that 1.0 is used and not 2.0. --Pierre Previous Comments: [2005-07-08 02:06:17] kni at exactal dot com The configure command is thus: Configure Command './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-openssl=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr/local' '--with-jpeg-dir=/usr/local' '--enable-ftp' '--enable-calendar' '--with-gd' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-png-dir=/usr/local' '--with-gettext=/usr/local' '--with-imap=/hsphere/shared' '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--enable-sockets' '--with-zip=/usr/local' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--enable-exif' '--with-regex=system' '--with-mhash=/usr/local' '--with-mcrypt=/usr/local' '--with-curl=/usr/local' '--with-ming=/usr/local' '--with-dom=/usr/local' '--with-iconv=/usr/local' '--with-ttf' '--enable-memory-limit' '--enable-sqlite-utf8' [2005-07-08 01:23:20] [EMAIL PROTECTED] No, but are you SURE that's the one PHP is linked with?? Are you compiling PHP with the bundled GD? (--with-gd without any paths) [2005-07-08 00:36:34] kni at exactal dot com The server is running freetype 2.1.7 Is this too old? [2005-07-07 08:53:00] [EMAIL PROTECTED] I just checked your phpinfo. It sounds like you have an old FT version, probably version 1. Please check that and update the freetype lib to a more recent (and decent) version if needed. --Pierre [2005-07-07 08:37:43] kni at exactal dot com http://d144091.tmp56.quadrahosting.com/resources/zapf.ttf I've tested it and reproduced the same problem with other fonts also. eg. http://d144091.tmp56.quadrahosting.com/resources/GNMI.TTF The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33599 -- Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn->Fbk]: poor quality imagettftext
ID: 33599 Updated by: [EMAIL PROTECTED] Reported By: kni at exactal dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: FreeBSD PHP Version: 4.3.11 Assigned To: pajoye New Comment: Remove freetype 1.x from the system (include development package) may help them... --Pierre ps: keep this report on feedback until you got an answer and write it here :) Previous Comments: [2005-07-08 02:31:56] kni at exactal dot com Thanks for the advice. I'll pass this onto the admin and see what they say. Meanwhile, our local environment (that works) is configured similarly (--with-ttf): Configure Command './configure' '--with-gd' '--with-jpeg-dir=../jpeg-6b/' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-zlib-dir=../zlib-1.2.1/' '--enable-sockets' '--with-mcrypt' '--with-ttf' '--enable-gd-native-ttf' '--with-freetype-dir=../freetype-2.1.8/' ...? [2005-07-08 02:20:17] [EMAIL PROTECTED] '--with-ttf' This is freetype 1.0 support. You activated both, it's no good idea. I have the feelings that 1.0 is used and not 2.0. --Pierre [2005-07-08 02:06:17] kni at exactal dot com The configure command is thus: Configure Command './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-openssl=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr/local' '--with-jpeg-dir=/usr/local' '--enable-ftp' '--enable-calendar' '--with-gd' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-png-dir=/usr/local' '--with-gettext=/usr/local' '--with-imap=/hsphere/shared' '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--enable-sockets' '--with-zip=/usr/local' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--enable-exif' '--with-regex=system' '--with-mhash=/usr/local' '--with-mcrypt=/usr/local' '--with-curl=/usr/local' '--with-ming=/usr/local' '--with-dom=/usr/local' '--with-iconv=/usr/local' '--with-ttf' '--enable-memory-limit' '--enable-sqlite-utf8' [2005-07-08 01:23:20] [EMAIL PROTECTED] No, but are you SURE that's the one PHP is linked with?? Are you compiling PHP with the bundled GD? (--with-gd without any paths) [2005-07-08 00:36:34] kni at exactal dot com The server is running freetype 2.1.7 Is this too old? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33599 -- Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33599 [Opn]: poor quality imagettftext
ID: 33599 Updated by: [EMAIL PROTECTED] Reported By: kni at exactal dot com Status: Open Bug Type: GD related Operating System: FreeBSD PHP Version: 4.3.11 Assigned To: pajoye New Comment: I'm sorry but if it works locally using ft 2 and not on your host, there is install problem. I suggest you to move to php-install and/or fbsd lists. Not much I can do without an access to the host. Neither I will do the setup for free. By the way, php+bundled gd +ft2 do work well on freebsd... A last try is to see if they active the smart subpixel support (could require a manual change in the ft2 include before make), but does not seem to be the problem. --Pierre Previous Comments: [2005-07-08 03:09:21] kni at exactal dot com --with-ttf has been removed. The problem remains. The configure command is now: './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr/local' '--with-jpeg-dir=/usr/local' '--enable-ftp' '--enable-calendar' '--with-gd' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-png-dir=/usr/local' '--with-gettext=/usr/local' '--with-imap=/hsphere/shared' '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--enable-sockets' '--with-zip=/usr/local' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--enable-exif' '--enable-mbstring' '--with-regex=system' '--with-mhash=/usr/local' '--with-mcrypt=/usr/local' '--with-curl=/usr/local' '--with-ming=/usr/local' '--with-dom=/usr/local' '--with-iconv=/usr/local' '--enable-memory-limit' '--enable-sqlite-utf8' [2005-07-08 02:43:03] [EMAIL PROTECTED] Remove freetype 1.x from the system (include development package) may help them... --Pierre ps: keep this report on feedback until you got an answer and write it here :) [2005-07-08 02:31:56] kni at exactal dot com Thanks for the advice. I'll pass this onto the admin and see what they say. Meanwhile, our local environment (that works) is configured similarly (--with-ttf): Configure Command './configure' '--with-gd' '--with-jpeg-dir=../jpeg-6b/' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-zlib-dir=../zlib-1.2.1/' '--enable-sockets' '--with-mcrypt' '--with-ttf' '--enable-gd-native-ttf' '--with-freetype-dir=../freetype-2.1.8/' ...? [2005-07-08 02:20:17] [EMAIL PROTECTED] '--with-ttf' This is freetype 1.0 support. You activated both, it's no good idea. I have the feelings that 1.0 is used and not 2.0. --Pierre [2005-07-08 02:06:17] kni at exactal dot com The configure command is thus: Configure Command './configure' '--localstatedir=/var/hsphere/php' '--with-apxs=/hsphere/shared/apache/bin/apxs' '--with-openssl=/usr' '--with-zlib=/usr' '--with-zlib-dir=/usr' '--with-bz2=/usr/local' '--with-jpeg-dir=/usr/local' '--enable-ftp' '--enable-calendar' '--with-gd' '--with-freetype-dir=/usr/local' '--enable-gd-native-ttf' '--with-png-dir=/usr/local' '--with-gettext=/usr/local' '--with-imap=/hsphere/shared' '--with-mysql=/usr/local' '--with-pgsql=/usr/local' '--enable-sockets' '--with-zip=/usr/local' '--enable-versioning' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--enable-exif' '--with-regex=system' '--with-mhash=/usr/local' '--with-mcrypt=/usr/local' '--with-curl=/usr/local' '--with-ming=/usr/local' '--with-dom=/usr/local' '--with-iconv=/usr/local' '--with-ttf' '--enable-memory-limit' '--enable-sqlite-utf8' The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/33599 -- Edit this bug report at http://bugs.php.net/?id=33599&edit=1
#33719 [Opn->Bgs]: foreach clash
ID: 33719
Updated by: [EMAIL PROTECTED]
Reported By: s dot masugata at digicom dot dnp dot co dot jp
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Solaris8
PHP Version: 4.4.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Use 2 different variables.
Previous Comments:
[2005-07-16 05:11:44] s dot masugata at digicom dot dnp dot co dot jp
Description:
KEY and VALUE of foreach are made the duplicate variable, strange
operation is
done.
Reproduce code:
---
$val ) {
// echo "debug {$val}\n";
// this comment is removed, stranger operation is done.
}
print_r( $arr );
?>
Expected result:
Array
(
[0] => 1
[1] => 123
[2] => 12345
)
Actual result:
--
Array
(
[0] => 1
[1] => 2
[2] =>
)
/usr/local/src/php-4.4.0/Zend/zend_execute.c(2436) : Freeing
0x0838B164 (12 bytes), script=f.php
--
Edit this bug report at http://bugs.php.net/?id=33719&edit=1
#30739 [Asn->Csd]: Writing on a Black BG
ID: 30739 Updated by: [EMAIL PROTECTED] Reported By: nate at highsocietyfreeride dot com -Status: Assigned +Status: Closed Bug Type: GD related Operating System: apache? PHP Version: 4.3.10-dev Assigned To: pajoye New Comment: 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. Hello, The bug was due to imagefill, it did not set back the alphablending to true. This is somehow required for font rendering with antialiasing. Btw, with true color images you do not need to fill the background with black, the default is black (0). a temporary fix is to call imagealphablending(true); after imagefill. Bug is fixed in cvs. Thanks for this report, --Pierre Previous Comments: [2004-11-10 09:39:15] [EMAIL PROTECTED] Confirmed with 4.3.10-dev, not reproducible with 5.0.x & 5.1.x branch. [2004-11-10 00:05:41] nate at highsocietyfreeride dot com Description: First off, I'm not sure what verison of PHP our servers use. My hosting service is IpowerWeb.com When I use imagettftext to write onto an image, it works fine, unless I allocate the color of 0,0,0. Even 1,1,1 works just fine. When I write to a complete black background the text shows up as rectangles, not the actual letters. The rectangles look like bounding boxes because they take the size of the actual letter its trying to print. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=30739&edit=1
#30229 [Opn->Ver]: (imagerectangle + alpha level > 0) = color bug
ID: 30229 Updated by: [EMAIL PROTECTED] Reported By: a25617 at alunos dot det dot ua dot pt -Status: Open +Status: Verified Bug Type: GD related Operating System: Windows XP PHP Version: Irrelevant -Assigned To: +Assigned To: pajoye New Comment: Got the fix, will commit asap. --Pierre Previous Comments: [2004-09-25 15:21:46] a25617 at alunos dot det dot ua dot pt Description: When using a transparency level above zero, drawing a rectangle will produce 4 dots in the corners. I think this is because the 4 lines of the rectangle are drawn and the corners will be overridden 2 times making the color on the corners darker than the rest. Reproduce code: --- Expected result: And grayed backgrounded image 100x100 with a blue rectangle 60x60 in the middle. Actual result: -- Everything is ok except the corners of the rectangle are darker. In some complex examples like drawing gantt or bar charts that bug stands out even more. -- Edit this bug report at http://bugs.php.net/?id=30229&edit=1
#30662 [Opn->Csd]: Unable to fill true color image with a high-alpha color (imagealphablending on)
ID: 30662 Updated by: [EMAIL PROTECTED] Reported By: ibrash at gmail dot com -Status: Open +Status: Closed Bug Type: GD related Operating System: Irrelevant PHP Version: 5.0.2 -Assigned To: +Assigned To: pajoye New Comment: 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. Fixed in HEAD. Merge to 5.0.x branch over the weekend. --Pierre Previous Comments: [2004-11-02 16:10:38] ibrash at gmail dot com Description: It seems that imagefill doesn't deal well with highly-transparent colors, causing PHP to use 100% of CPU and never finish executing the imagefill (i.e., seems like an infinite loop). Anything at or above an alpha setting of 85 in the imagecolorallocatealpha call seems to trigger this behavior. Tested on both Linux (built from source) and Windows XP (php.net packaged version) with same results. Configure line on Linux is ./configure --with-gd --with-jpeg-dir --with-zlib-dir Reproduce code: --- Expected result: Script to run to completion. Actual result: -- Script never ends (unless max_execution_time is set, of course) -- Edit this bug report at http://bugs.php.net/?id=30662&edit=1
#30242 [Opn->Csd]: ...topalette creates 2 colors from 1 color image
ID: 30242 Updated by: [EMAIL PROTECTED] Reported By: pmpp at sapo dot pt -Status: Open +Status: Closed Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.9RC3 -Assigned To: +Assigned To: pajoye New Comment: 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. Fixed in head. 5.0 commit over the weekend. --Pierre Previous Comments: [2004-09-26 13:15:00] pmpp at sapo dot pt Description: I create a truecolor image, fill it with 1 color, then I make that color transparent, but when I convert the image to palette, I get 1 pixel of a slightest different color of the first one, shifted 1pixel to the right of every pixel near a transparent pixel. [GD Version] => bundled (2.0.28 compatible) Reproduce code: --- Expected result: I expect to have all the image transparent. Actual result: -- With a more complex image, it's as I had moved a selection of the NON transparent image, full of a slightest different color of the one I made transparent, moved 1pixel to the right in the background. -- Edit this bug report at http://bugs.php.net/?id=30242&edit=1
#30483 [Opn->Fbk]: imagefill() not working on images larger than 181x181
ID: 30483 Updated by: [EMAIL PROTECTED] Reported By: bjoneson at mchsi dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Fedora Core 2 PHP Version: 5.0.2 -Assigned To: +Assigned To: pajoye New Comment: Be sure that php uses the bundled library. If you have gd and gd-devel packages installes (rpms or sources installed), you may have conflicts or wrong gd used. Remove or move gd files out of the include and lib path and then start again the php configuration and compilation (after a make clean). In fact the "official" imagefill is more buggy than the bundled one :) --Pierre Previous Comments: [2004-10-25 17:36:22] bjoneson at mchsi dot com It's the stock RPM that comes with the Fedora 2 distribution "libpng-devel-1.2.2-22.i386.rpm" [2004-10-23 10:36:44] [EMAIL PROTECTED] What's your version of libpng ? Reproduce code works fine for me with any images. [2004-10-19 23:09:44] bjoneson at mchsi dot com OK... though it was no short order, I re-compiled php and pointed --with-gd at the new installation using the following config: ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-curl --with-gd=/usr/local --with-zlib-dir=/usr/include --with-freetype-dir=/usr/local When I do this, the problem goes away. This leads me to believe that the problem is most likely with the bundled version of gd in php5. If there is any other information I can provide, please let me know. [2004-10-19 21:39:09] bjoneson at mchsi dot com Things are only getting weirder... I downloaded, compiled, and installed the newest version of gd. I then recompiled php using the same config line (didn't point --with-gd at anything). Now imagefill() seems to work at 182x182 and below but not above. (I gained one pixel). I'm perplexed. [2004-10-19 20:23:58] bjoneson at mchsi dot com ./configure --with-apxs2=/usr/local/apache2/bin/apxs --with-mysql --with-curl --with-gd --with-zlib-dir=/usr/include --with-jpeg-dir=/usr/lib The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30483 -- Edit this bug report at http://bugs.php.net/?id=30483&edit=1
#30652 [Opn->Fbk]: imagettftext different output os
ID: 30652
Updated by: [EMAIL PROTECTED]
Reported By: info at paulinternet dot nl
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Windows & Linux
PHP Version: 4.3.9
-Assigned To:
+Assigned To: pajoye
New Comment:
Please provide valid URL. These urls (the images) do not work .
--Pierre
Previous Comments:
[2004-11-04 19:52:30] info at paulinternet dot nl
Description:
Imagettftext produces different images on Windows and Linux.
I used the Verdana font, but this happends on more(maybe all) fonts.
GD version: bundled (2.0.28 compatible)
Windows output: http://www.paulinternet.nl/php.net/Windows.png
Linux output: http://www.paulinternet.nl/php.net/Linux.png
Verdana font: http://www.paulinternet.nl/php.net/Verdana.ttf
Reproduce code:
---
header("Content-type: image/png");
$Image = imagecreate(200, 24);
imagecolorallocate($Image, 0, 0, 0);
$Kleur = imagecolorallocate($Image, 255, 255, 255);
imagettftext($Image, 16, 0, 2, 18, $Kleur,
"Pagina's/Tekst/Verdana.ttf", "I have a problem");
imagepng($Image);
imagedestroy($Image);
[2004-11-01 16:00:00] info at paulinternet dot nl
Description:
I can run this script on the localhost and on the server of my hosting
provider.
The image on the localhost is a bit difference from the image on the
server.
Is this a bug? If not, how can I get on my computer the same output as
on the server?
My phpinfo: http://www.paulinternet.nl/php.net/Localhost.htm
Server phpinfo: http://www.paulinternet.nl/php.net/Server.htm
My output: http://www.paulinternet.nl/php.net/Localhost.png
Server output: http://www.paulinternet.nl/php.net/Server.png
Verdana font: http://www.paulinternet.nl/php.net/Verdana.ttf
Reproduce code:
---
header("Content-type: image/png");
$Image = imagecreate(200, 24);
imagecolorallocate($Image, 0, 0, 0);
$Kleur = imagecolorallocate($Image, 255, 255, 255);
imagettftext($Image, 16, 0, 2, 18, $Kleur,
"Pagina's/Tekst/Verdana.ttf", "I have a problem");
imagepng($Image);
imagedestroy($Image);
--
Edit this bug report at http://bugs.php.net/?id=30652&edit=1
#30595 [Opn->Bgs]: Imagecopyresampled function bug
ID: 30595 Updated by: [EMAIL PROTECTED] Reported By: lunter at interia dot pl -Status: Open +Status: Bogus Bug Type: GD related Operating System: WinXP SP2 PHP Version: 5.0.2 -Assigned To: +Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php imagecopyresampled uses a resampling using weight of each original pixels in the destination image. That means even by resizing by a ratio of 0.99, you will have part of the image that will differ, in your case the edges of your square. --Pierre Previous Comments: [2004-10-28 11:02:46] lunter at interia dot pl Description: Imagecopyresampled function bug: Original image: Any one-color square. After resized (reduce 1 pixel width and heihgt): Two colors square with noise !!! Example with PHP code: http://www.pc44.pl/goorol/ImagecopyresampledBug.zip Reproduce code: --- http://www.pc44.pl/goorol/ImagecopyresampledBug.zip Expected result: One-color 99x99 square. Actual result: -- Two-colors with NOISE 99x99 square. Example with PHP code: http://www.pc44.pl/goorol/ImagecopyresampledBug.zip -- Edit this bug report at http://bugs.php.net/?id=30595&edit=1
#29558 [Opn]: Memory leak when calling imageCreateFromJPEG and imagecreatetruecolor in loop
ID: 29558
Updated by: [EMAIL PROTECTED]
Reported By: zsheran at yahoo dot com
Status: Open
Bug Type: GD related
Operating System: Redhat 9
PHP Version: 4.3.7
New Comment:
Are you talking about real memory leaks (memory not freed at the end of
the process) or about the memory used by php?
--Pierre
Previous Comments:
[2004-08-10 10:09:46] klaus at deam dot org
maybe this is related to bug #29460?
[2004-08-08 05:34:47] zsheran at yahoo dot com
Thanks smacvicar.
I made the following change at the bottom of the function:
replaced
unset($source_picture);
unset($target_picture);
with
imagedestroy($source_picture);
imagedestroy($target_picture);
The problem persists. It still leaks memory the same way it did before.
I didn't know imagedestroy() had to be used instead of unset(); my
fault. But now it looks even more like a bug to me...
[2004-08-07 04:43:35] smacvicar at gmail dot com
http://uk.php.net/manual/en/function.imagedestroy.php
[2004-08-07 00:14:14] zsheran at yahoo dot com
Description:
I call the function below from a loop about 17,000 times to resize JPGs
which are about 20k each. Note that $source_file is a URL. I run the
script from CLI. By the time the script finishes after ~270 minutes,
the PHP process uses 340MB of RAM; it grows slowly and steadily to that
size. I unset the variables at the end of the function but it makes no
difference. Now 340MB is about the size of those 17,000 pics. For some
reason, the fetched images are not freed from memory, probaly only upon
finishing the script. But since it runs in a loop, it adds up at becomes
eventually a problem. It works but it would be great if the memory leak
could be fixed; I expect the number of images to grow to six digit
numbers in the future.
Thanks for your time.
Reproduce code:
---
function resize_picture ($source_file, $target_file) {
$source_picture = imageCreateFromJPEG($source_file);
if ($source_picture) {
$picsize = @getimagesize($source_file); // get source image
size
$source_x = $picsize[0]; // source image width
$source_y = $picsize[1]; // source image height
#create image $target_picture
$target_picture = imagecreatetruecolor(320, 240);
#Resize $source_picture and copy it into $target_picture.
imagecopyresampled($target_picture,$source_picture,0,0,0,0,320,240,$source_x,$source_y);
#Create jpeg from $target_picture. Save as $target_file
imagejpeg ($target_picture,"/path/$target_file",80);
unset($source_picture);
unset($target_picture);
}
}
--
Edit this bug report at http://bugs.php.net/?id=29558&edit=1
#29558 [Opn->Fbk]: Memory leak when calling imageCreateFromJPEG and imagecreatetruecolor in loop
ID: 29558
Updated by: [EMAIL PROTECTED]
Reported By: zsheran at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: Redhat 9
PHP Version: 4.3.7
Previous Comments:
[2004-11-19 13:46:48] [EMAIL PROTECTED]
Are you talking about real memory leaks (memory not freed at the end of
the process) or about the memory used by php?
--Pierre
[2004-08-10 10:09:46] klaus at deam dot org
maybe this is related to bug #29460?
[2004-08-08 05:34:47] zsheran at yahoo dot com
Thanks smacvicar.
I made the following change at the bottom of the function:
replaced
unset($source_picture);
unset($target_picture);
with
imagedestroy($source_picture);
imagedestroy($target_picture);
The problem persists. It still leaks memory the same way it did before.
I didn't know imagedestroy() had to be used instead of unset(); my
fault. But now it looks even more like a bug to me...
[2004-08-07 04:43:35] smacvicar at gmail dot com
http://uk.php.net/manual/en/function.imagedestroy.php
[2004-08-07 00:14:14] zsheran at yahoo dot com
Description:
I call the function below from a loop about 17,000 times to resize JPGs
which are about 20k each. Note that $source_file is a URL. I run the
script from CLI. By the time the script finishes after ~270 minutes,
the PHP process uses 340MB of RAM; it grows slowly and steadily to that
size. I unset the variables at the end of the function but it makes no
difference. Now 340MB is about the size of those 17,000 pics. For some
reason, the fetched images are not freed from memory, probaly only upon
finishing the script. But since it runs in a loop, it adds up at becomes
eventually a problem. It works but it would be great if the memory leak
could be fixed; I expect the number of images to grow to six digit
numbers in the future.
Thanks for your time.
Reproduce code:
---
function resize_picture ($source_file, $target_file) {
$source_picture = imageCreateFromJPEG($source_file);
if ($source_picture) {
$picsize = @getimagesize($source_file); // get source image
size
$source_x = $picsize[0]; // source image width
$source_y = $picsize[1]; // source image height
#create image $target_picture
$target_picture = imagecreatetruecolor(320, 240);
#Resize $source_picture and copy it into $target_picture.
imagecopyresampled($target_picture,$source_picture,0,0,0,0,320,240,$source_x,$source_y);
#Create jpeg from $target_picture. Save as $target_file
imagejpeg ($target_picture,"/path/$target_file",80);
unset($source_picture);
unset($target_picture);
}
}
--
Edit this bug report at http://bugs.php.net/?id=29558&edit=1
#29315 [Opn->Bgs]: Bug in imagecopyresampled
ID: 29315
Updated by: [EMAIL PROTECTED]
Reported By: k at ailis dot de
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Linux
PHP Version: 4.3.8
-Assigned To:
+Assigned To: pajoye
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Side effect of the resizing method in imagecopyresampled.
Cannot be "fixed".
ImageCopyResamples is not good for each kind of images but is not that
bad for a "all-in-one" usage.
--Pierre
Previous Comments:
[2004-07-27 15:52:11] k at ailis dot de
No. I've downloaded and opened your bug.png with GIMP and
I still see blue snow around the second line. So the bug
is still there.
You must use a viewer which can display alpha-transparency
like GIMP, ImageMagick or a capable browser like Mozilla
to see the bug.
[2004-07-27 15:36:52] [EMAIL PROTECTED]
http://tony2004.phpclub.net/dev/tmp/bug.png - is this what you need?
If yes - please, try the next CVS snapshot, it should be fixed now.
[2004-07-23 09:26:02] k at ailis dot de
I've installed this snapshot, The bug is still present.
Here is the output of gd_info():
array(11) {
["GD Version"]=>
string(27) "bundled (2.0.28 compatible)"
["FreeType Support"]=>
bool(true)
["FreeType Linkage"]=>
string(13) "with freetype"
["T1Lib Support"]=>
bool(true)
["GIF Read Support"]=>
bool(true)
["GIF Create Support"]=>
bool(true)
["JPG Support"]=>
bool(true)
["PNG Support"]=>
bool(true)
["WBMP Support"]=>
bool(true)
["XBM Support"]=>
bool(true)
["JIS-mapped Japanese Font Support"]=>
bool(true)
}
[2004-07-23 01:10:28] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-07-22 09:56:53] k at ailis dot de
Description:
Hello,
I've also send this bug to Boutell (because it is a bug in
the GD library, not in PHP) but I have the feeling that
I'll not get an answer because of the message I got after
submitting the bug.. So maybe someone is able to fix this
bug in the GD library which is bundled with PHP.
There seems to be a bug in gdImageCopyResampled which is
triggered if an alphatransparent image is resampled. The
bug can be reproduced with GD 2.0.28 (and also with the
library bundled with PHP 4.3.8) with the code at the
bottom of this message (It's a C source. I'm putting a PHP
source into the "reproduce code" box)
This example code sets the background color of the
resulting image to transparent so it's easier to see the
bug. Resampling an alpha-transparent image to a
"binary-even" size (2^x, for example: 64x64) works fine,
but other values (like 127x127 in this example) creates
alpha transparent artifacts. Depending on the destination
size of the resampling the artifacts are very different.
To see these artifacts just compile the following code and
start it. You will end up with an out.png which has two
lines in it. The first one is correct (was resized to
64x64), the second one (resized to 127x127) has snow
around the line (only visible if you display the image
with a viewer supporting PNG transparency)
#include
int main(int argc, char *argv[])
{
gdImagePtr alpha_image, test_image;
FILE *file;
int transparent, black, blue;
// Create an alpha-transparent image with a black line
in it
alpha_image = gdImageCreateTrueColor(128, 128);
gdImageAlphaBlending(alpha_image, 0);
gdImageSaveAlpha(alpha_image, 1);
transparent = gdImageColorAllocateAlpha(alpha_image,
0, 0, 0, 127);
black = gdImageColorAllocate(alpha_image, 0, 0, 0);
gdImageFilledRectangle(alpha_image, 0, 0, 128, 128,
transparent);
gdImageLine(alpha_image, 0, 0, 128, 128, black);
// Create a test background image
test_image = gdImageCreateTrueColor(256, 256);
blue = gdImageColorAllocate(test_image, 0, 0, 256);
gdImageColorTransparent(test_image, blue);
gdImageFilledRectangle(test_image, 0, 0, 256, 256,
blue);
// Resample the alpha-transparent image onto
#28598 [Ver]: ImageTTFText doesn't work with some fonts
ID: 28598
Updated by: [EMAIL PROTECTED]
Reported By: supermario at gmx dot net
Status: Verified
Bug Type: GD related
Operating System: Linux / WinXP
-PHP Version: 4.3.6
+PHP Version: 4.3.4+
-Assigned To:
+Assigned To: pajoye
New Comment:
Found work around. A fix in GD to work with MS Symbols does not take
care if we relly have a Symbol family font. Many faces could be
available. But checking the font family ('Symbol') seems to make it.
Commit over the weekend.
--Pierre
Previous Comments:
[2004-06-04 12:54:38] supermario at gmx dot net
In PHP 4.3.7 the bug with that font still occurs.
[2004-06-02 09:23:54] [EMAIL PROTECTED]
The font sounds ok and works with FT2 (outside php).
--Pierre
[2004-06-02 01:00:16] supermario at gmx dot net
@Pierre, I sent you a mail with used font, PHP script and results of
PHP 4.3.5RC1 and PHP 4.3.7RC1.
[2004-06-01 23:13:06] [EMAIL PROTECTED]
Please provide a link (or mail) to the font and a short to reproduce
your problem (create an image, draw the text).
--Pierre
[2004-06-01 23:00:25] supermario at gmx dot net
On Linux I use the bundled GD lib and Freetype 2.1.4 and on Windows I
use the included GD2 DLL.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28598
--
Edit this bug report at http://bugs.php.net/?id=28598&edit=1
#30289 [Opn->Csd]: imagettfbbox returns wrong information
ID: 30289 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GD related Operating System: Linux PHP Version: 4.3.9 New Comment: Seems to be fixed using the right ft. Previous Comments: [2004-10-04 14:28:36] [EMAIL PROTECTED] After having PHP recompiled with the following items in the ./configure string everything started working again: '--disable-gd-native-ttf' It would thus seem to be a problem with GD's native TTF Functions... [2004-10-01 15:59:16] [EMAIL PROTECTED] Comparing it to a similar server, still running 4.3.0, which DOES give the right results, I noticed a small difference in the compile strings: OK: '--with-ttf' WRONG: '--enable-gd-native-ttf' '--with-t1lib' '--with-ttf' [2004-10-01 10:24:23] [EMAIL PROTECTED] >From phpinfo()'s configure string: --- './configure' *snap* '--with-gd' '--enable-gd-native-ttf' '--with-t1lib' '--with-jpeg-dir=/usr/lib' '--with-png-dir=/usr/lib' '--with-ttf' *snap* --- >From the GD table in phpinfo(): -- GD GD Support enabled GD Version bundled (2.0.28 compatible) FreeType Supportenabled FreeType Linkagewith TTF library T1Lib Support enabled GIF Read Supportenabled GIF Create Support enabled JPG Support enabled PNG Support enabled WBMP Supportenabled XBM Support enabled -- [2004-09-30 22:43:12] [EMAIL PROTECTED] Works fine with 4.3.9 i got here using bundled libgd, are you using bundled lib gd or the external one? What GD related configuration flags do you have enabled? [2004-09-30 11:12:33] [EMAIL PROTECTED] Description: When running imagettfbbox() against a font, the returned values are way off, in the billions or negative billions. Reproduce code: --- print_r(imagettfbbox(9, 0, "HelvCondBlack.TTF", 'HOME')); HelvCondBlack.TTF is available for download at http://www.campai.nl/fonttest/HelvCondBlack.TTF Expected result: Array ( [0] => -1 [1] => -1 [2] => 21 [3] => -1 [4] => 21 [5] => -8 [6] => -1 [7] => -8 ) Actual result: -- Array ( [0] => 1080490528 [1] => 153840736 [2] => -1073754904 [3] => 1081352559 [4] => 1080490544 [5] => 1080487896 [6] => -1073754872 [7] => 1079718188 ) (The 2nd item, [1], will fluctuate mildly between requests) -- Edit this bug report at http://bugs.php.net/?id=30289&edit=1
#28598 [Ver->Fbk]: ImageTTFText doesn't work with some fonts
ID: 28598
Updated by: [EMAIL PROTECTED]
Reported By: supermario at gmx dot net
-Status: Verified
+Status: Feedback
Bug Type: GD related
Operating System: Linux / WinXP
PHP Version: 4.3.4+
Assigned To: pajoye
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
A fix has been commited (head), please give it a try.
--Pierre
Previous Comments:
[2004-11-19 18:00:52] [EMAIL PROTECTED]
Found work around. A fix in GD to work with MS Symbols does not take
care if we relly have a Symbol family font. Many faces could be
available. But checking the font family ('Symbol') seems to make it.
Commit over the weekend.
--Pierre
[2004-06-04 12:54:38] supermario at gmx dot net
In PHP 4.3.7 the bug with that font still occurs.
[2004-06-02 09:23:54] [EMAIL PROTECTED]
The font sounds ok and works with FT2 (outside php).
--Pierre
[2004-06-02 01:00:16] supermario at gmx dot net
@Pierre, I sent you a mail with used font, PHP script and results of
PHP 4.3.5RC1 and PHP 4.3.7RC1.
[2004-06-01 23:13:06] [EMAIL PROTECTED]
Please provide a link (or mail) to the font and a short to reproduce
your problem (create an image, draw the text).
--Pierre
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/28598
--
Edit this bug report at http://bugs.php.net/?id=28598&edit=1
#30229 [Ver->Fbk]: (imagerectangle + alpha level > 0) = color bug
ID: 30229 Updated by: [EMAIL PROTECTED] Reported By: a25617 at alunos dot det dot ua dot pt -Status: Verified +Status: Feedback Bug Type: GD related Operating System: Windows XP PHP Version: Irrelevant Assigned To: pajoye New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Commited to 4.3 --Pierre Previous Comments: [2004-11-17 21:13:33] [EMAIL PROTECTED] Got the fix, will commit asap. --Pierre [2004-09-25 15:21:46] a25617 at alunos dot det dot ua dot pt Description: When using a transparency level above zero, drawing a rectangle will produce 4 dots in the corners. I think this is because the 4 lines of the rectangle are drawn and the corners will be overridden 2 times making the color on the corners darker than the rest. Reproduce code: --- Expected result: And grayed backgrounded image 100x100 with a blue rectangle 60x60 in the middle. Actual result: -- Everything is ok except the corners of the rectangle are darker. In some complex examples like drawing gantt or bar charts that bug stands out even more. -- Edit this bug report at http://bugs.php.net/?id=30229&edit=1
#30863 [Opn->Bgs]: imagecolortransparent and imagetruecolortopalette don't mix
ID: 30863 Updated by: [EMAIL PROTECTED] Reported By: hp at oeri dot ch -Status: Open +Status: Bogus Bug Type: GD related Operating System: Windows XP PHP Version: 5.0.2 -Assigned To: +Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use dithering to get out of that. The color approximation (even with 2colors..) is "better". --Pierre Previous Comments: [2004-11-22 16:53:06] hp at oeri dot ch Description: If I create a truecolor image and a) set a color as transparent b) use imagetruecolortopalette the result is offset by one in "x" direction and a black vertical line at x=0. Leaving out either a or b gives the correct result (no offset). Didn't find this bug anywhere, am however unable to compile on Windows. Reproduce code: --- Expected result: palette image, 750x400 with a rectangle along the borders Actual result: -- palette image, 750x400, with a rectangle open to the right (offset 1) -- Edit this bug report at http://bugs.php.net/?id=30863&edit=1
#30483 [NoF->Bgs]: imagefill() not working on images larger than 181x181
ID: 30483
Updated by: [EMAIL PROTECTED]
Reported By: bjoneson at mchsi dot com
-Status: No Feedback
+Status: Bogus
Bug Type: GD related
Operating System: Fedora Core 2
PHP Version: 5.0.2
Assigned To: pajoye
New Comment:
Do not use external gd ("--with-gd" not "--with-gd=/usr"
Set it as bogus, obvioulsy wrong lib/broken install.
--Pierre
Previous Comments:
[2004-11-28 00:23:51] myguyroin at hotmail dot com
This is happening on PHP 4.3.9 too! I tried the compile method above,
and it didn't fix my problem.
[2004-11-27 01:00:02] 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".
[2004-11-19 11:23:47] [EMAIL PROTECTED]
Be sure that php uses the bundled library. If you have gd and gd-devel
packages installes (rpms or sources installed), you may have conflicts
or wrong gd used.
Remove or move gd files out of the include and lib path and then start
again the php configuration and compilation (after a make clean).
In fact the "official" imagefill is more buggy than the bundled one :)
--Pierre
[2004-10-25 17:36:22] bjoneson at mchsi dot com
It's the stock RPM that comes with the Fedora 2 distribution
"libpng-devel-1.2.2-22.i386.rpm"
[2004-10-23 10:36:44] [EMAIL PROTECTED]
What's your version of libpng ?
Reproduce code works fine for me with any images.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30483
--
Edit this bug report at http://bugs.php.net/?id=30483&edit=1
#30120 [Asn]: imagettftext() and imagettfbbox() has superfluous optional parameter
ID: 30120 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: GD related Operating System: Irrelevant PHP Version: 5.0.1 Assigned To: pajoye New Comment: As far as I can see, the amount of arguments did not change after this patch. Even if it did, which side effect are youl talking about? --Pierre Previous Comments: [2004-11-28 17:01:21] [EMAIL PROTECTED] Before patch, imagettftext() could be called with 4 parameters. Now it's possible to call it with 4 or 5 parameter but the 5th parameter is superfluous. The patch was made to allow 5th parameter of imagefttext() be optional but unnecessary side-effect was that 5th parameter of imagettftext() was allowed. [2004-11-28 15:32:41] [EMAIL PROTECTED] I'm not quite sure I understand what are you talking about, Jakub. Could you plz explain how Ilia could add parameter while he made it optional? [2004-09-16 17:09:03] [EMAIL PROTECTED] Description: Since PHP 4.3.5 (precisely since patch http://cvs.php.net/diff.php/php-src/ext/gd/gd.c?r1=1.279&r2=1.280&ty=u), these two functions has superfluous optional parameter. -- Edit this bug report at http://bugs.php.net/?id=30120&edit=1
#30942 [Opn->Fbk]: imageCreateFromPng() gives fatal error
ID: 30942
Updated by: [EMAIL PROTECTED]
Reported By: hkh at netnords dot dk
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: win XP
PHP Version: 4.3.8
-Assigned To:
+Assigned To: pajoye
New Comment:
Are you using the bundled gd library ("configure --with-gd" and not
--with-gd=/path/to/gd).
Cannot reproduce it with all branches and 4.3.8.
--Pierre
Previous Comments:
[2004-11-30 13:20:51] hkh at netnords dot dk
Description:
Sometimes when calling imageCreateFromPng() it produces a fatal error
instead of returning an empty string.
Reproduce code:
---
/*
* The code are placed inside this function
* &getImage($IfilePathName)
*/
return imageCreateFromPng($IfilePathName);
Expected result:
An empty string.
After the documentation the function should return a resource on
succes, and on error an empty string.
Actual result:
--
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Invalid chunk length. in
C:\Documents and Settings\hkh\Desktop\php\desktop\bmpNoget.inc.php
on line 98
--
Edit this bug report at http://bugs.php.net/?id=30942&edit=1
#30942 [Opn]: imageCreateFromPng() gives fatal error
ID: 30942
Updated by: [EMAIL PROTECTED]
Reported By: hkh at netnords dot dk
Status: Open
Bug Type: GD related
Operating System: win XP
PHP Version: 4.3.8
Assigned To: pajoye
New Comment:
Please provide an url with these images please (if possible both bmp
and png).
--Pierre
Previous Comments:
[2004-12-02 11:19:31] hkh at netnords dot dk
I found out witch pictures, who gives this error. It's png's created
with acdsee (used to convert bmp's to png's). I have experinced no
trouble with these png's in other programs.
I also found out, some of the png's gives a
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Too many IDAT's found
Run a phpinfo() who tells me
GD Version bundled (2.0.23 compatible)
The ini file contains this
extension=php_gd2.dll
[2004-11-30 13:49:53] [EMAIL PROTECTED]
Are you using the bundled gd library ("configure --with-gd" and not
--with-gd=/path/to/gd).
Cannot reproduce it with all branches and 4.3.8.
--Pierre
[2004-11-30 13:20:51] hkh at netnords dot dk
Description:
Sometimes when calling imageCreateFromPng() it produces a fatal error
instead of returning an empty string.
Reproduce code:
---
/*
* The code are placed inside this function
* &getImage($IfilePathName)
*/
return imageCreateFromPng($IfilePathName);
Expected result:
An empty string.
After the documentation the function should return a resource on
succes, and on error an empty string.
Actual result:
--
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Invalid chunk length. in
C:\Documents and Settings\hkh\Desktop\php\desktop\bmpNoget.inc.php
on line 98
--
Edit this bug report at http://bugs.php.net/?id=30942&edit=1
#30942 [Opn->Asn]: imageCreateFromPng() gives fatal error
ID: 30942
Updated by: [EMAIL PROTECTED]
Reported By: hkh at netnords dot dk
-Status: Open
+Status: Assigned
Bug Type: GD related
Operating System: win XP
PHP Version: 4.3.8
Assigned To: pajoye
New Comment:
The fact is you will not be able to read these images without using
another libpng (1.0.6 and later), compiled with:
#define PNG_SETJMP_NOT_SUPPORTED
#define PNG_ABORT()
The png files are not valid.
The fix will be to change the error to a warning and return false.
--Pierre
Previous Comments:
[2004-12-02 12:01:05] hkh at netnords dot dk
http://www.hanskejserhansen.dk/png/
I don't have the original pictures. They was saved from a homepage via
a browser (Don't know witch because i use four different) to my
harddesk.
I tried to find the original pictures, but now they are jpg's not
bmp's. sorry.
[2004-12-02 11:35:38] [EMAIL PROTECTED]
Please provide an url with these images please (if possible both bmp
and png).
--Pierre
[2004-12-02 11:19:31] hkh at netnords dot dk
I found out witch pictures, who gives this error. It's png's created
with acdsee (used to convert bmp's to png's). I have experinced no
trouble with these png's in other programs.
I also found out, some of the png's gives a
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Too many IDAT's found
Run a phpinfo() who tells me
GD Version bundled (2.0.23 compatible)
The ini file contains this
extension=php_gd2.dll
[2004-11-30 13:49:53] [EMAIL PROTECTED]
Are you using the bundled gd library ("configure --with-gd" and not
--with-gd=/path/to/gd).
Cannot reproduce it with all branches and 4.3.8.
--Pierre
[2004-11-30 13:20:51] hkh at netnords dot dk
Description:
Sometimes when calling imageCreateFromPng() it produces a fatal error
instead of returning an empty string.
Reproduce code:
---
/*
* The code are placed inside this function
* &getImage($IfilePathName)
*/
return imageCreateFromPng($IfilePathName);
Expected result:
An empty string.
After the documentation the function should return a resource on
succes, and on error an empty string.
Actual result:
--
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Invalid chunk length. in
C:\Documents and Settings\hkh\Desktop\php\desktop\bmpNoget.inc.php
on line 98
--
Edit this bug report at http://bugs.php.net/?id=30942&edit=1
#30991 [Opn->Bgs]: problem in image transparancy
ID: 30991 Updated by: [EMAIL PROTECTED] Reported By: mars at talash dot net -Status: Open +Status: Bogus Bug Type: GD related Operating System: windows NT/2000 PHP Version: 4.3.9 -Assigned To: +Assigned To: pajoye New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php You can use only one transparent color. With formats that support alpha channel, use the alpha channel. --Pierre Previous Comments: [2004-12-06 05:57:27] mars at talash dot net Description: In my php.ini file, i enabled GD only. ie) uncomment that one line for gd configuration Reproduce code: --- $logoImage is png image. $image1 = ImageCreateFromPNG($logoImage); $color=imagecolorat($image1,$mouseX,$mouseY); imagecolortransparent($image1,$color); ImagePNG($image1,"$logoImage"); after transparant a color in image. save that image . what the problem is, after that i transparent another color in that image ,last color is only tranperant. previous color revoke it's original place. for example : imagecolortransparent($image1,$color); imagecolortransparent($image1,$color1); imagecolortransparent($image1,$color2); imagecolortransparent($image1,$color3); Expected result: after excution only that image transperant for $color3 but i want a transparent image with all four color. what can i do? any other functions.. Actual result: -- only image with last color transparancy. -- Edit this bug report at http://bugs.php.net/?id=30991&edit=1
#31043 [Opn->Bgs]: Error trying to build with GD 2.0.33
ID: 31043 Updated by: [EMAIL PROTECTED] Reported By: phpbb dot mods at phpmix dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: RHEL 3 PHP Version: 4.3.9 New Comment: Compiled php with an extern GD lib works. I have the feeling that you should first fix your setup. Sounds like you are missing some files from gd-devel. --Pierre Previous Comments: [2004-12-12 19:03:28] phpbb dot mods at phpmix dot com Anyway... the PHP manual suggests it IS possible to compile PHP with a GD other than the one bundled in the package (using the --with-gd[=DIR] parameter). However, this does NOT seem to be the case. ...or? [2004-12-10 04:41:38] phpbb dot mods at phpmix dot com I meant _write_ support for GIF _Animation_. I believe 4.3.9 adds support for writing GIFs, but not GIF animations. A bug in the manual? ..it suggests it is possible to compile PHP with a different GD library than the one PHP provides as an extension. I'm guessing this is not completely correct. :( Will this patch be included in 4.3.10 ? http://www.zend.com/lists/php-dev/200411/msg00171.html [2004-12-10 02:03:36] phpbb dot mods at phpmix dot com I've tried without success. The only reference I've about it is here: http://www.zend.com/lists/php-dev/200411/msg00171.html http://hyvatti.iki.fi/~jaakko/sw/ Do you mean the GIF animation functions are already implemented? If so, could you please give a pointer on how to get more information about new functions? Thanks [2004-12-10 01:20:59] [EMAIL PROTECTED] So does bundled GD lib as of PHP 4.3.9 [2004-12-09 23:31:25] phpbb dot mods at phpmix dot com Main reason is GD 2.0.33 now supports writing GIF animations. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31043 -- Edit this bug report at http://bugs.php.net/?id=31043&edit=1
#30942 [Asn->Bgs]: imageCreateFromPng() gives fatal error
ID: 30942
Updated by: [EMAIL PROTECTED]
Reported By: hkh at netnords dot dk
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: win XP
PHP Version: 4.3.8
Assigned To: pajoye
New Comment:
Not a developer issue. Fix your image conversion tool.
--Pierre
Previous Comments:
[2004-12-02 13:36:04] [EMAIL PROTECTED]
The fact is you will not be able to read these images without using
another libpng (1.0.6 and later), compiled with:
#define PNG_SETJMP_NOT_SUPPORTED
#define PNG_ABORT()
The png files are not valid.
The fix will be to change the error to a warning and return false.
--Pierre
[2004-12-02 12:01:05] hkh at netnords dot dk
http://www.hanskejserhansen.dk/png/
I don't have the original pictures. They was saved from a homepage via
a browser (Don't know witch because i use four different) to my
harddesk.
I tried to find the original pictures, but now they are jpg's not
bmp's. sorry.
[2004-12-02 11:35:38] [EMAIL PROTECTED]
Please provide an url with these images please (if possible both bmp
and png).
--Pierre
[2004-12-02 11:19:31] hkh at netnords dot dk
I found out witch pictures, who gives this error. It's png's created
with acdsee (used to convert bmp's to png's). I have experinced no
trouble with these png's in other programs.
I also found out, some of the png's gives a
Fatal error: imagecreatefrompng(): gd-png: fatal libpng error:
Too many IDAT's found
Run a phpinfo() who tells me
GD Version bundled (2.0.23 compatible)
The ini file contains this
extension=php_gd2.dll
[2004-11-30 13:49:53] [EMAIL PROTECTED]
Are you using the bundled gd library ("configure --with-gd" and not
--with-gd=/path/to/gd).
Cannot reproduce it with all branches and 4.3.8.
--Pierre
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/30942
--
Edit this bug report at http://bugs.php.net/?id=30942&edit=1
#30371 [Opn->Fbk]: Implement gdImageSharpen
ID: 30371 Updated by: [EMAIL PROTECTED] Reported By: chris at lodesys dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: all PHP Version: 5.0.1 -Assigned To: +Assigned To: pajoye New Comment: You can use the MeanRemoval filter available in php5+. It's not a perfect solutions for every needs but works well fo common uses. Does it fit your needs? --Pierre Previous Comments: [2004-10-09 07:46:24] chris at lodesys dot com Description: The current interface to the GD image library includes access to a number of GD functions, including the imagecopyresampled and imagecopyresized. When shrinking an image, the new smaller image will be "blurry" and needs to be sharpened. The GD image library includes a gdImageSharpen function. Can it be implemented in PHP (as ImageSharpen())? -- Edit this bug report at http://bugs.php.net/?id=30371&edit=1
#31726 [Bgs]: GD -JPEG-JFIF error
ID: 31726 Updated by: [EMAIL PROTECTED] Reported By: skyfox at isp dot ee Status: Bogus Bug Type: *Graphics related Operating System: Debian PHP Version: 4.3.10 New Comment: We do not want to support broken images. Even if a broken IE can load them, accepting invalid images/data as valid data is the best to run in troubles. --Pierre Previous Comments: [2005-01-31 16:37:07] skyfox at isp dot ee Derick - try it by IE ;) no errors [2005-01-31 11:25:48] [EMAIL PROTECTED] When opening it in GIMP I get the following error: Corrupt JPEG data: 145 extraneous bytes before marked 0xd9 EXIF data will be ignored. [2005-01-31 11:19:22] skyfox at isp dot ee http://www.amur.ee/~deni/60672 this is not BROKEN PHOTO! [2005-01-28 21:49:12] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Have you tried to look at these images yourself? 60125 is definitely broken as even my viewer refuses to show it up correctly - only a half of the image is viewable. [2005-01-28 08:43:28] skyfox at isp dot ee http://www.amur.ee/~deni/60125 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/31726 -- Edit this bug report at http://bugs.php.net/?id=31726&edit=1
#31726 [Bgs]: GD -JPEG-JFIF error
ID: 31726
Updated by: [EMAIL PROTECTED]
Reported By: skyfox at isp dot ee
Status: Bogus
Bug Type: *Graphics related
Operating System: Debian
PHP Version: 4.3.10
New Comment:
Please stop to comment this bug. Your images are not valid. Fix them or
ask your clients to fix them.
--Pierre
Previous Comments:
[2005-02-01 09:38:14] skyfox at isp dot ee
then verify broken upload photo not work!
this is from my code:
if ($_FILES["photo"]["error"]==UPLOAD_ERR_NO_FILE)
{return($lns[49]);}
if ($_FILES["photo"]["error"]==UPLOAD_ERR_PARTIAL)
{return($lns[50]);}
if (($_FILES["photo"]["error"]==UPLOAD_ERR_INI_SIZE)
||($_FILES["photo"]["error"]==UPLOAD_ERR_FORM_SIZE))
{return($lns[51]);}
if
($_FILES["photo"]["error"]<>UPLOAD_ERR_OK){return('Error:'.$_FILES["photo"]["error"]);}
[2005-02-01 09:28:10] [EMAIL PROTECTED]
We do not want to support broken images. Even if a broken IE can load
them, accepting invalid images/data as valid data is the best to run in
troubles.
--Pierre
[2005-01-31 16:37:07] skyfox at isp dot ee
Derick - try it by IE ;) no errors
[2005-01-31 11:25:48] [EMAIL PROTECTED]
When opening it in GIMP I get the following error:
Corrupt JPEG data: 145 extraneous bytes before marked 0xd9
EXIF data will be ignored.
[2005-01-31 11:19:22] skyfox at isp dot ee
http://www.amur.ee/~deni/60672
this is not BROKEN PHOTO!
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31726
--
Edit this bug report at http://bugs.php.net/?id=31726&edit=1
#25132 [Opn]: if compiled with --enable-gd-native-ttf images with ->accents show font errors
ID: 25132 Updated by: [EMAIL PROTECTED] Reported By: mail_fidel at yahoo dot com Status: Open Bug Type: GD related Operating System: FreeBSD 4.7 PHP Version: 4.3.3RC4 New Comment: hello, do you have the ttf font used by your script? What do you mean by "not only the accented charanter disapeared but also the next character"? "buen día" and "buen d a",only the "i" disapeared. Which freetype version do you use? pierre Previous Comments: [2003-08-18 12:54:28] mail_fidel at yahoo dot com At the end of the comment I wrote: "If you remove the config option (--enable-gd-native-ttf) then php behaves as before." but what I really mean was that without --enable-gd-native-ttf , php makes the images right as it used to do before 4.3.3RC1. [2003-08-18 12:50:12] mail_fidel at yahoo dot com Description: If when compiling you use the: --enable-gd-native-ttf then you will have trouble with accents in graphics. The behavior is as follows: Lets say you want an image with the words: "hello world". I works as espected and you get the text right. Now if you want the words: "buen día" (pay attention to the accent over the "i") then, the text that displays on the image is "buen d a" not only the accented charanter disapeared but also the next character. If you remove the config option (--enable-gd-native-ttf) then php behaves as before. -- Edit this bug report at http://bugs.php.net/?id=25132&edit=1
#25132 [Fbk]: if compiled with --enable-gd-native-ttf images with ->accents show font errors
ID: 25132 Updated by: [EMAIL PROTECTED] Reported By: mail_fidel at yahoo dot com Status: Feedback Bug Type: GD related Operating System: FreeBSD 4.7 PHP Version: 4.3.3RC4 -Assigned To: +Assigned To: pajoye New Comment: everythings works fine here. Using bundled GD library, freetype 2.1.3 and the standart arial windows font. Send the required infos asap if you still reproduce this bug using freetype2 (last release or 2.1.3+) and bundled GD. pierre Previous Comments: [2003-08-18 16:35:32] [EMAIL PROTECTED] Also, let us know what parameter you specified to configure. it's possible you turned on jis-conv feature with --enable-gd-jis-conv. [2003-08-18 15:14:16] [EMAIL PROTECTED] hello, do you have the ttf font used by your script? What do you mean by "not only the accented charanter disapeared but also the next character"? "buen día" and "buen d a",only the "i" disapeared. Which freetype version do you use? pierre [2003-08-18 12:54:28] mail_fidel at yahoo dot com At the end of the comment I wrote: "If you remove the config option (--enable-gd-native-ttf) then php behaves as before." but what I really mean was that without --enable-gd-native-ttf , php makes the images right as it used to do before 4.3.3RC1. [2003-08-18 12:50:12] mail_fidel at yahoo dot com Description: If when compiling you use the: --enable-gd-native-ttf then you will have trouble with accents in graphics. The behavior is as follows: Lets say you want an image with the words: "hello world". I works as espected and you get the text right. Now if you want the words: "buen día" (pay attention to the accent over the "i") then, the text that displays on the image is "buen d a" not only the accented charanter disapeared but also the next character. If you remove the config option (--enable-gd-native-ttf) then php behaves as before. -- Edit this bug report at http://bugs.php.net/?id=25132&edit=1
#25144 [Bgs]: GD library 2.0.12 not work at IIS 6
ID: 25144 Updated by: [EMAIL PROTECTED] Reported By: rs at kunstbar dot tv Status: Bogus Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: "- phpinfo() shows NO GD Support ENABLE" It is clear enough imo. Fix this install/upgrade problem first. pierre Previous Comments: [2003-08-19 05:24:41] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. ..shouldn't it be pretty normal that they funcs don't work if you don't have gd enabled ? go ask this kind of basic support questions elsewhere, no bug here. [2003-08-19 05:17:41] rs at kunstbar dot tv Description: bundled GD library with GD 2.0.12 don't work on IIS 6 with Windows Server 2003 - build 3790. Status: - PHP 4.3.2 works (phpmyadmin 2.5.2 works) - no Script which use GD-LIB works - PHP 4.3.2 installed as: sapi\php4isapi.dll - extension=php_gd2.dll is enable - No Error, script only shows no Image. - Path is set to: extension_dir = "C:\\PHP\\extensions" (also try: extension_dir = "C:\PHP\extensions" - phpinfo() shows NO GD Support ENABLE - same GD Scripts works on W2k and IIS 5 -Roland- Reproduce code: --- Use Windows Server 2003 - build 3790 with IIS 6 and try GD-LIB 2.0.12. Expected result: GD lib create Image Actual result: -- GD-LIB don't work. -- Edit this bug report at http://bugs.php.net/?id=25144&edit=1
#25132 [Opn]: if compiled with --enable-gd-native-ttf images with ->accents show font errors
ID: 25132
Updated by: [EMAIL PROTECTED]
Reported By: mail_fidel at yahoo dot com
Status: Open
Bug Type: GD related
Operating System: FreeBSD 4.7
PHP Version: 4.3.3RC2
Assigned To: pajoye
New Comment:
Can you try this simple script instead?
$im = imagecreatetruecolor(200,200);
$black = imagecolorallocate($im, 255,0,0);
imagettftext($im, 20, 0, 10, 20, $black, "arial.ttf",
"buen día");
imagepng($im, 'res.png');
On which platform do you work?
pierre
Previous Comments:
[2003-08-19 10:27:01] mail_fidel at yahoo dot com
This are the config options:
Configure Command => './configure' '--enable-versioning'
'--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr'
'--disable-a
ll' '--with-regex=php' '--enable-discard-path' '--enable-bcmath'
'--enable-ctype' '--with-dom=/usr/local' '--with-dom-xslt=/usr/local'
'-
-with-dom-exslt=/usr/local' '--enable-filepro' '--with-gd'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=
/usr/local' '--with-xpm-dir=/usr/local' '--with-imap=/usr/local'
'--with-imap-ssl=/usr/local' '--enable-mbstring' '--enable-mbregex'
'--w
ith-mysql=/usr/local' '--enable-overload' '--with-pcre-regex=yes'
'--enable-posix' '--with-readline' '--enable-session'
'--enable-tokeniz
er' '--enable-xml' '--with-expat-dir=/usr/local' '--with-zlib=yes'
'--prefix=/usr/local' 'i386-portbld-freebsd4.7'
This is my working built, without --enable-gd-native-ttf
Freetype version:
freetype2-2.1.4_1
Example code:
function getImage($font,$string,$point,$color,$bgcolor)
{
$ses = session_id();
$fileName = $ses."_.png";
$measures = imagettfbbox ( $point, "0", $this->fonts_path.$font,
$string);
$width = abs($measures[4] - $measures[0])+20;
$upper = abs($measures[5])+5;
$under = abs($measures[1])+5;
$height = $upper + $under;
$image = imagecreate($width, $height);
//Allocate some colors.
$color = eregi_replace("#","",$color);
$ri = hexdec(substr($color, 0, 2));
$gi = hexdec(substr($color, 2, 2));
$bi = hexdec(substr($color, 4, 2));
$bgcolor = eregi_replace("#","",$bgcolor);
$rb = hexdec(substr($bgcolor, 0, 2));
$gb = hexdec(substr($bgcolor, 2, 2));
$bb = hexdec(substr($bgcolor, 4, 2));
$bg_color = imagecolorallocate($image,$rb ,$gb,$bb);
$typeface_color = imagecolorallocate($image, $ri, $gi, $bi);
imagecolortransparent($image,$bg_color);
imagefilledrectangle($image, 0, 0, $width, $height, $bg_color);
imagettftext($image, $point, 0, 10, $upper+2,
$typeface_color,$this->fonts_path.$font, $string);
$path = $this->temp_path;
imagepng($image,$path.$fileName);
//Finally, free up the memory allocated for the image.
imagedestroy($image);
return($fileName);
}
when trying to solve the problem we change the image type from png to
gif to jpg to see if this was the problem. We upgrade freetype and GD.
Then I read that php 4.3.3 was using some "recomended" native gd code
and when I saw the --enable-gd-native-ttf I decided to turned off and
the scripts start working again.
I'm sure is not a font related problem, first because it worked just
before the update, and second bacause we have a big library of ttf
fonts and we test it with all of them (since some fonts do not have
accent characters we generate an image with each one to test them)
Also, I made a mistake in the description with the example "buen día"
the output was "buen d ". A customer of us wrote this "todo por tus
células" and the output was: "todo por tus c ulas". If any one knows
spanish he/she can realize how embarrassing and funny is is (original
text "all for your cells" output text "all for you ass").
[2003-08-18 18:31:23] [EMAIL PROTECTED]
everythings works fine here. Using bundled GD library, freetype 2.1.3
and the standart arial windows font.
Send the required infos asap if you still reproduce this bug using
freetype2 (last release or 2.1.3+) and bundled GD.
pierre
[2003-08-18 16:35:32] [EMAIL PROTECTED]
Also, let us know what parameter you specified to configure. it's
possible you turned on jis-conv feature
with --enable-gd-jis-conv.
--
#25438 [Opn->Bgs]: GD Fails drawing more than one image with TTF at one time
ID: 25438 Updated by: [EMAIL PROTECTED] Reported By: sven at weih dot de -Status: Open +Status: Bogus Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.3 New Comment: This is a problem related to the freetype lib. Already reported here. We cannot fix this issue. Previous Comments: [2003-09-09 12:10:41] sven at weih dot de here is some code for reproducing the error. Note, it works sometimes, but mostly there are errors. --- code for sample.php --- --- end of sample.php --- --- code of reproduce.php '."\n"; } ?> -- end of reproduce.php --- Both files are in one directory. Calling reproduce.php will bring up the error. [2003-09-08 18:53:11] [EMAIL PROTECTED] Please provide a short example. [2003-09-08 16:49:31] sven at weih dot de Description: Hi, i am drawing images using Apache 2 and GD2. Whenever I draw two images at the same time, there is a locking problem with the True Type Font. In some cases Apache 2 crashes, in others php throws a failure. Sven. -- Edit this bug report at http://bugs.php.net/?id=25438&edit=1
#27468 [Asn->Csd]: foreach in __destruct() causes segfault
ID: 27468 Updated by: [EMAIL PROTECTED] Reported By: davojan at mail dot ru -Status: Assigned +Status: Closed Bug Type: Zend Engine 2 problem Operating System: FreeBSD 4.7-RELEASE PHP Version: 5CVS-2004-03-02 (dev) Assigned To: andi New Comment: 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. Previous Comments: [2004-03-02 15:50:04] [EMAIL PROTECTED] Verified on Linux, assigning to Andi. [2004-03-02 15:46:10] davojan at mail dot ru Description: PHP crashes if foreach for a member of the class called in __destruct(). It doesn't matter - does the member exist or not, is it array or not - result is the same. Note, that in php5b4 it works fine. Expected result is what I get from it. Reproduce code: --- x as $x); } } new foo(); echo 'OK'; ?> Expected result: Warning: Invalid argument supplied for foreach() in /usr/local/www/data-dist/ils/admin/test/static.php on line 4 OK Actual result: -- Program received signal SIGSEGV, Segmentation fault. 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 88 zend_hash_destroy(object->properties); (gdb) bt #0 0x28531d8d in zend_objects_free_object_storage (object=0x) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects.c:88 #1 0x28534883 in zend_objects_store_del_ref (zobject=0x80e82f0) at /usr/ports/distfiles/php5-200403021630/Zend/zend_objects_API.c:139 #2 0x28519cde in _zval_dtor (zvalue=0x80e82f0, __zend_filename=0x2859dd20 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c", __zend_lineno=358) at /usr/ports/distfiles/php5-200403021630/Zend/zend_variables.c:61 #3 0x2850e5fe in _zval_ptr_dtor (zval_ptr=0xbfbfe120, __zend_filename=0x285a3160 "/usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c", __zend_lineno=3820) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute_API.c:358 #4 0x28549472 in zend_jmp_no_ctor_handler (execute_data=0xbfbfe168, opline=0x80e85e0, op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:3820 #5 0x28541aeb in execute (op_array=0x80e80c8) at /usr/ports/distfiles/php5-200403021630/Zend/zend_execute.c:1339 #6 0x2851c4d0 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/ports/distfiles/php5-200403021630/Zend/zend.c:1041 #7 0x284d23b3 in php_execute_script (primary_file=0xbfbff7b0) at /usr/ports/distfiles/php5-200403021630/main/main.c:1650 #8 0x2854e83e in apache_php_module_main (r=0x81fb038, display_source_mode=0) at /usr/ports/distfiles/php5-200403021630/sapi/apache/sapi_apache.c:54 #9 0x2854f8c8 in send_php (r=0x81fb038, display_source_mode=0, filename=0x81fcb10 "/usr/local/www/data/ils/admin/test/static.php") at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:621 #10 0x2854f93b in send_parsed_php (r=0x81fb038) at /usr/ports/distfiles/php5-200403021630/sapi/apache/mod_php5.c:636 #11 0x8053a44 in ap_invoke_handler () #12 0x806398d in process_request_internal () #13 0x80639ec in ap_process_request () #14 0x805cdae in child_main () #15 0x805cf40 in make_child () #16 0x805d05d in startup_children () #17 0x805d5b0 in standalone_main () #18 0x805dcab in main () #19 0x804fc39 in _start () -- Edit this bug report at http://bugs.php.net/?id=27468&edit=1
#27439 [Ctl->Csd]: Segfault in CVS
ID: 27439
Updated by: [EMAIL PROTECTED]
Reported By: kase at gmx dot net
-Status: Critical
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: all
PHP Version: 5CVS-2004-02-29 (dev)
-Assigned To:
+Assigned To: andi
New Comment:
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.
Previous Comments:
[2004-03-01 13:39:02] kase at gmx dot net
Yes, it will also crashes, if it is an array of strings, sorry. I don´t
know anymore, how I modified my code yesterday, to get this error
output.
Today, i found another class, that crashes with segfault in a foreach.
This time, it is an array of _correct_ objects, but it crashes, too.
The backtrace of this crash is very similar. I don`t have a short
reproduce code yet.
[2004-03-01 06:41:42] reiersol at online dot no
In my code, it crashes even if it's an array of strings. Copying the
array first seems to make it work.
[2004-02-29 11:16:22] kase at gmx dot net
Description:
I get a segfault with this script:
Reproduce code:
---
array as $foo ) {
$foo->any_method();
}
}
}
$test = new test();
$test->start();
?>
Expected result:
If $this->array is an array with objects, the method any_method()
should be called on $foo. (works well)
If $this->array is an array with strings, int, ..., php should display
an error. (works well) (Fatal error: Call to a member function
any_method() on a non-object in /var/www/legendz/web/test/test.php5 on
line 5 )
If $this->array is an empty array, nothing should happen. (but php
crashes)
Actual result:
--
(gdb) bt
#0 0x082128b4 in zend_fetch_obj_w_handler (execute_data=0xbfffd840,
opline=0x404e9518, op_array=0x404dd7d4)
at /home/kase/php5-200402271430/Zend/zend_execute.c:2044
#1 0x08210be0 in execute (op_array=0x404dd7d4)
at /home/kase/php5-200402271430/Zend/zend_execute.c:1339
#2 0x082143c9 in zend_do_fcall_common_helper
(execute_data=0xbfffd9f0,
opline=0x404e84dc, op_array=0x404dd018)
at /home/kase/php5-200402271430/Zend/zend_execute.c:2675
#3 0x082147f6 in zend_do_fcall_by_name_handler
(execute_data=0xbfffd9f0,
opline=0x404e84dc, op_array=0x404dd018)
at /home/kase/php5-200402271430/Zend/zend_execute.c:2757
#4 0x08210be0 in execute (op_array=0x404dd018)
at /home/kase/php5-200402271430/Zend/zend_execute.c:1339
#5 0x081f0289 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/kase/php5-200402271430/Zend/zend.c:1041
#6 0x081b0a13 in php_execute_script (primary_file=0xbd48)
at /home/kase/php5-200402271430/main/main.c:1650
#7 0x0821d16c in main (argc=2, argv=0xbde4)
at /home/kase/php5-200402271430/sapi/cgi/cgi_main.c:1573
--
Edit this bug report at http://bugs.php.net/?id=27439&edit=1
#27398 [Ver->Csd]: Installing PEAR (go-pear.bat) causes Application Error
ID: 27398 Updated by: [EMAIL PROTECTED] Reported By: WPinegar at healthtech dot net -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2004-02-26 New Comment: 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. Previous Comments: [2004-02-26 15:28:34] patrick dot schnorbus at tuxcenter dot net PEAR support seems to be totally broken in current CVS. The this happend somewhere between the 200402241430 and 200402251630 snaps (200402241430 was the last with working PEAR). aries:/usr/src/php5-200402261630# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/ local/apache2/build/libtool' libphp5.la /usr/local/ apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.so /usr/local/apache2/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/src/php5-200402261630/libs' chmod 755 /usr/local/apache2/modules/libphp5.so [activating module `php5' in /usr/local/apache2/conf/ httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Fatal error: Declaration of PEAR_Installer::download() must be compatible with that of PEAR_Downloader::download() in /usr/src/php5-200402261630/ pear/PEAR/Installer.php on line 49 make[1]: *** [install-pear-installer] Fehler 255 make: *** [install-pear] Fehler 2 aries:/usr/src/php5-200402261630# export LC_ALL=C aries:/usr/src/php5-200402261630# make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/ local/apache2/build/libtool' libphp5.la /usr/local/ apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ cp .libs/libphp5.so /usr/local/apache2/modules/libphp5.so cp .libs/libphp5.lai /usr/local/apache2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /usr/src/php5-200402261630/libs' chmod 755 /usr/local/apache2/modules/libphp5.so [activating module `php5' in /usr/local/apache2/conf/ httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ Fatal error: Declaration of PEAR_Installer::download() must be compatible with that of PEAR_Downloader::download() in /usr/src/php5-200402261630/ pear/PEAR/Installer.php on line 49 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 Installing PHP5 without PEAR works. -- Pat [2004-02-25 23:41:06] [EMAIL PROTECTED] Here's the callstack when you run go-pear.bat: zend_fetch_obj_w_handler(_zend_execute_data * 0x0012f788, _zend_op * 0x015985c8, _zend_op_array * 0x01595ad8, void * * * 0x00972980) line 2044 + 12 bytes execute(_zend_op_array * 0x01595ad8, void * * * 0x00972980) line 1339 + 23 bytes zend_do_fcall_common_helper(_zend_execute_data * 0x0012f910, _zend_op * 0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line 2675 + 34 bytes zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012f910, _zend_op * 0x015995c8, _zend_op_array * 0x01594868, void * * * 0x00972980) line 2757 + 21 bytes execute(_zend_op_array * 0x01594868, void * * * 0x00972980) line 1339 + 23 bytes zend_do_fcall_common_helper(_zend_execute_data * 0x0012fa98, _zend_op * 0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line 2675 + 34 bytes zend_do_fcall_by_name_handler(_zend_execute_data * 0x0012fa98, _zend_op * 0x00c1fd88, _zend_op_array * 0x00a9f818, void * * * 0x00972980) line 2757 + 21 bytes execute(_zend_op_array * 0x00a9f818, void * * * 0x00972980) line 1339 + 23 bytes zend_execute_scripts(int 8, void * * * 0x00972980, _zval_struct * * 0x, int 3) line 1041 + 34 bytes php_execute_script(_zend_file_handle * 0x0012ff48, void * * * 0x00972980) line 1650 + 27 bytes main(int 3, char * * 0x00972580) line 941 + 17 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e814c7() [2004-02-25 16:12:40] WPinegar at healthtech dot net Description: While attempting to install PEAR via the command go-pear.bat (found in the \PHP directory) I received an application error in php.exe modu
#27238 [Opn->Csd]: iptcparse() function misses some fields
ID: 27238 Updated by: [EMAIL PROTECTED] Reported By: philip at nancarrow dot net -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows and Linux PHP Version: 4.3.4 -Assigned To: +Assigned To: pajoye New Comment: 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. Previous Comments: [2004-02-13 10:40:02] philip at nancarrow dot net Pierre, OK sure, I've put two JPEGs that include IIM record 1 at: http://www.nancarrow.net/download/testpic1_latin1.jpg [Latin1 encoded English] and http://www.nancarrow.net/download/testpic2_utf8.jpg [UTF8 encoded Chinese] The IPTC/NAA (aka "IIM") spec is freely downloadable from http://www.iptc.org/download/download.php?fn=IIMV4.1.pdf and this details all records include record 1. Appendix C lists the currently defined character sets, which is specified in dataset 1:90. Note the strange IPTC terminology - an "octet" is a byte, so "octet 2/5" means 0x25. The character set sequence starts with ESC, so where it says ISO-8859-1 is "intermediate character 2/12 to 2/15" followed by "octet 4/1" this would be something like: ESC,0x2F,0x41 or "ESC/A". Similarly UTF8 is ESC,2/5,4/7 or "ESC%G". Where the spec says "intermediate character 2/12 to 2/15" most creators writing the file use the end character, ie. 2/15 in this case. I'm not sure that PHP really needs to know about the encoding, does it ? Since strings are just byte sequences in PHP I guess it's down to the application to do the appropriate encoding/decoding... as long as they have access to the character set of course ! Thanks Philip [2004-02-13 09:29:23] [EMAIL PROTECTED] > I can provide you with JPEG files containing IIM record 1 > if required; they're quite common in the news industry. Please do :) If you can provide an URL with some images with the required fields and a txt file for the expected result. Note that I never read the charset part in any docs about IPTC standart. Have you a link that describes it? pierre [2004-02-13 06:27:10] philip at nancarrow dot net Description: The iptcparse() function (GD extension) only returns IPTC/NAA records 2 and upward, skipping past record 1. This appears to be by design, but means that the returned data is incomplete, for example the "destination" dataset 1:05 is missing. Worse that this is the fact that "coded character set" (1:90) is missing, and without this value the encoding of the data is unknown (for example if 1:90 specifies ESC,%,G the data is UTF8 encoded). I assume that the current implementation is defaulting to ASCII or Latin1 encoding. I can provide you with JPEG files containing IIM record 1 if required; they're quite common in the news industry. Thank you -- Edit this bug report at http://bugs.php.net/?id=27238&edit=1
#27582 [Fbk->Ver]: ImageFillToBorder act weird with alpha channel on alphablending image
ID: 27582 Updated by: [EMAIL PROTECTED] Reported By: panda dot management at free dot fr -Status: Feedback +Status: Verified Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.5RC3 New Comment: Hello, Verified with HEAD. Segfault in libgd function, infinite recursion. I will try to fix it asap. pierre Previous Comments: [2004-03-13 05:03:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-03-12 18:52:27] panda dot management at free dot fr Description: Hello! ImageFillToBorder seems to act strangely (no output) when using alpha channel (?) on color and / or bordercolor values, on an alphablending image. Configuration: ** winxp apache 2.0.48 php 4.3.4 / 4.3.5RC3 gd2 module loaded Reproduce code: --- Expected result: Do work as supposed to, or output some error. Actual result: -- Actual result: ** Browser hangs and output an alert "Document contains no data". I'm not experienced enough to give you more debug details... but it obviously break something... Additionnal comment: ** The values that trigger the bug seems to be pretty much random. You can reproduce the problem with: $bordercolor=ImageColorAllocateAlpha($im, 0, 254, 0, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); Or even reproduce it with: $bordercolor=ImageColorAllocate($im, 0, 254, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); (wich is much more logical on an alphablending image...) But odly it works ok with: $bordercolor=ImageColorAllocateAlpha($im, 0, 0, 0, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); I can't find any coherence in the problematic values, except that they involve alpha channel. If this is a doc problem, or if I missed something, please forgive this report... Anyway, long life to php. Olivier -- Edit this bug report at http://bugs.php.net/?id=27582&edit=1
#8074 [Opn->Fbk]: IPTC parse
ID: 8074 Updated by: [EMAIL PROTECTED] Reported By: serge at globalbeach dot com -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Linux RH 7.0 PHP Version: 4.0.3pl1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2000-12-03 08:31:09] [EMAIL PROTECTED] Not a bug, moving to feature reqs [2000-12-01 19:40:14] serge at globalbeach dot com Will IPTCparse work with Photoshop 6.0 saved images? See info about changes here: http://www.robgalbraith.com/diginews/2000-12/2000_12_01_ps6_iptc.html Serge -- Edit this bug report at http://bugs.php.net/?id=8074&edit=1
#27582 [Ver->Csd]: ImageFillToBorder act weird with alpha channel on alphablending image
ID: 27582 Updated by: [EMAIL PROTECTED] Reported By: panda dot management at free dot fr -Status: Verified +Status: Closed Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.5RC3 -Assigned To: +Assigned To: pajoye New Comment: 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. This bug is fixed in HEAD (php5). It will be fixed too in php4 (PHP_4_3) later this weekend. thanks for the small reproduce script, pierre Previous Comments: [2004-03-13 05:10:55] [EMAIL PROTECTED] Hello, Verified with HEAD. Segfault in libgd function, infinite recursion. I will try to fix it asap. pierre [2004-03-13 05:03:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2004-03-12 18:52:27] panda dot management at free dot fr Description: Hello! ImageFillToBorder seems to act strangely (no output) when using alpha channel (?) on color and / or bordercolor values, on an alphablending image. Configuration: ** winxp apache 2.0.48 php 4.3.4 / 4.3.5RC3 gd2 module loaded Reproduce code: --- Expected result: Do work as supposed to, or output some error. Actual result: -- Actual result: ** Browser hangs and output an alert "Document contains no data". I'm not experienced enough to give you more debug details... but it obviously break something... Additionnal comment: ** The values that trigger the bug seems to be pretty much random. You can reproduce the problem with: $bordercolor=ImageColorAllocateAlpha($im, 0, 254, 0, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); Or even reproduce it with: $bordercolor=ImageColorAllocate($im, 0, 254, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); (wich is much more logical on an alphablending image...) But odly it works ok with: $bordercolor=ImageColorAllocateAlpha($im, 0, 0, 0, 0); $color = ImageColorAllocateAlpha($im, 0, 255, 255, 75); I can't find any coherence in the problematic values, except that they involve alpha channel. If this is a doc problem, or if I missed something, please forgive this report... Anyway, long life to php. Olivier -- Edit this bug report at http://bugs.php.net/?id=27582&edit=1
#27591 [Opn->Fbk]: JPEG 2000 IPTC not found by GetImageSize + iptcparse
ID: 27591 Updated by: [EMAIL PROTECTED] Reported By: tom at kornack dot com -Status: Open +Status: Feedback Bug Type: GetImageSize related Operating System: Mac OS X 10.3.2 PHP Version: 5CVS-2004-03-14 (dev) New Comment: Hello, It seems that this jp2 image is broken. None of the tools I used to test can open it, even not the jp2 reference tools. Which tools have been used to create this file? pierre Previous Comments: [2004-03-14 00:42:50] tom at kornack dot com Description: JPEG 2000 IPTC blocks are not returned by the GetImageSize imageinfo array. This information is increasingly important with the next generation of digital cameras that will call for compressed, 16-bit files. Reproduce code: --- A sample JPEG 2000 image file is available here: http://listera.org/pub/iptc/iptctestimage.jp2 This code is also available here: http://listera.org/pub/iptc/iptctest.phps A sample JPEG that does work is available here: http://listera.org/pub/iptc/iptctestimage.jpg Expected result: Title: Title Metadata Actual result: -- Title: -- Edit this bug report at http://bugs.php.net/?id=27591&edit=1
#27582 [Opn->Sus]: ImageFillToBorder on alphablending image now loose alpha on fill color
ID: 27582 Updated by: [EMAIL PROTECTED] Reported By: panda dot management at free dot fr -Status: Open +Status: Suspended Bug Type: GD related Operating System: Windows XP PHP Version: 4.3.5RC4-dev Mar 14 2004 22:12:48 Assigned To: pajoye New Comment: Hello, Sorry, this function does not work with blending mode. I was forced to desactivate it. Using a blending mode will result in an infinite loop and recursive calls with the current implementation (blending over endlessly). A second case where it fails is when you have a lot of small open segments (see ext/gd/tests/bug27852_1.phpt). I cannot fix it before the next php4 and php5 (rc1) release. I have to rewrite the function. pierre Previous Comments: [2004-03-14 21:51:57] panda dot management at free dot fr heu... I just reopened the bug, cause it seemed to me that it's related. Should I have filled a new one instead? Best regards. Olivier [2004-03-14 21:47:34] panda dot management at free dot fr Hello, Using PHP Version 4.3.5RC4-dev Mar 14 2004 22:12:48. The first described bug is fixed, but we now loose the ability to use a fill color with an alpha channel. Reproduce: ** '; ?> Actual result: ** imagefilltoborder doesn't take the alpha channel of fill color into account. Expected result: imagefilltoborder (on alpha blending images) should use alpha channel on the color to fill, IMHO because: - when using Non Alpha Blending images, it does. - and imagefill on alphablending images does also. Additionnal comment: Thank you Pierre for the quick fix to the first bug! Hope this sequel will find its solution soon. See ya! [2004-03-13 13:31:30] [EMAIL PROTECTED] 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. This bug is fixed in HEAD (php5). It will be fixed too in php4 (PHP_4_3) later this weekend. thanks for the small reproduce script, pierre [2004-03-13 05:10:55] [EMAIL PROTECTED] Hello, Verified with HEAD. Segfault in libgd function, infinite recursion. I will try to fix it asap. pierre [2004-03-13 05:03:55] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27582 -- Edit this bug report at http://bugs.php.net/?id=27582&edit=1
#27385 [Ver->WFx]: GD: Eliptical fills don't work with translucent colours
ID: 27385 Updated by: [EMAIL PROTECTED] Reported By: nih at phlux dot co dot uk -Status: Verified +Status: Wont fix Bug Type: GD related Operating System: * PHP Version: 4CVS, 5CVS (2004-02-24) New Comment: hello, This is a known problem of the gd arcs functions. It's due to the ellipse approximation which is based on the radius angle and not on the x/y positions. That means that the filled lines can be drawn many times. A complete rewrite of this funciton is required, something like what is done in imagefilledellipse. pierre Previous Comments: [2004-02-24 18:30:17] nih at phlux dot co dot uk I used the bundled GD library. [2004-02-24 18:14:25] [EMAIL PROTECTED] Did you use the bundled GD library or the external one. (In short: what is your configure line?) [2004-02-24 17:51:49] nih at phlux dot co dot uk Description: The elliptical drawing tools in the GD library that offer a fill function do not correctly render the fill when using a translucent colour. It would appear that the fill is drawn by a series of lines from the centre point to each pixel around the edge of the ellipse or arc, thus pixels near the centre are drawn over many times, thus increasing the effective alpha of those pixels. Reproduce code: --- Expected result: There should be a PNG image output of an arc of a 170px diameter going from a bearing of 090 to a bearing of 175 in 50% transparent pure RGB blue (0, 0, 255). Actual result: -- The transparency isn't correct, the closer towards the centre of the arc the pixel is, the lower it's transparency (I'm almost certain it's because they are being redrawn over and over). -- Edit this bug report at http://bugs.php.net/?id=27385&edit=1
#27636 [Opn->Fbk]: imagecreatefromjpeg fails if the picture is too high
ID: 27636
Updated by: [EMAIL PROTECTED]
Reported By: mito at nic dot fi
-Status: Open
+Status: Feedback
Bug Type: GD related
Operating System: FreeBSD 4.8-RELEASE #0
PHP Version: 4.3.4
New Comment:
Hello,
both work perfectly here. Either using cli, or apache, php5 or php4.
Please add the memory_limit option to your php.ini. Default is 8M, try
more.
pierre
Previous Comments:
[2004-03-18 13:25:56] mito at nic dot fi
Image that works:
Dimensions: 1600x1200
Size on disk: 575KB
Image that doesn't work:
Dimensions: 1200x1600
Size on disk: 491KB
[2004-03-18 13:18:21] mito at nic dot fi
That is not the case. The test pic I provided that the code works with
is larger than the pic that causes the failure. Therefor if it were up
to the picture being too large and using too much memory it would occur
with the larger picture too wouldn't it?
[2004-03-18 12:29:37] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You probably have a memory_limit enabled and it is reached
trying to allocate memory to store a big image.
[2004-03-18 12:18:02] mito at nic dot fi
Description:
When calling imagecreatefromjpeg("image.jpg"); where image.jpg is
1200x1600 pixels of size it causes an internal server error with no
actual error output just a plank page. I'm not sure if it's because the
picture is too high or does it occur every time if the height is larger
than width. I tested with many similar jpgs that were produced in same
way ( same digicam ), but were 1600x1200 and it worked fine. I also
tested the same code in 4.3.2 running on Windows and it worked fine
with both sizes of picture.
Reproduce code:
---
See it at: http://mindanao.globat.com/~hopea.net/errortest/
Expected result:
Done!
Actual result:
--
500 Internal system error and a blank page (in IE).
--
Edit this bug report at http://bugs.php.net/?id=27636&edit=1
#27934 [Opn->Bgs]: Images computed by GD Library incorrect
ID: 27934 Updated by: [EMAIL PROTECTED] Reported By: new at springtimesoftware dot com -Status: Open +Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4.3.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Use imagecreatetruecolor to work true color images else you will with only 256 colors (incl. background). Previous Comments: [2004-04-09 12:46:14] new at springtimesoftware dot com Description: Hi. I think I'm encountering an error in the GD Library. This happens in PHP Version 4.3.5 running on Linux but does not happen in Version 4.1.2 running on Windows 98. Please download and unzip http://www.springtimesoftware.com/public/gd-error-bmp.zip . This file contains a bitmap file that shows two images. The top image, a picture of a building, was generated by browsing to the file gd-error-jpg.php (see below) on my local computer (system "localhost"). The second image is generated by browsing to the same file located on a remote server, at address http://www.springtimesoftware.com/public/gd-error-jpg.php . Note that the second image appears to be grayed, which is an error. I've localized the error to the "imagecopy" function. I don't have the source files, so I can't debug. You can browse to http://www.springtimesoftware.com/public/bldg.jpg to see the original image which is processed by gd-error-jpg.php. I thought that bldg.jpg might have an incorrect format, but using sunset.jpg, which was generated by a different program, also results in an error (the image is black this time). Here are the contents of the gd-error-jpg.php file: Thanks, David -- Edit this bug report at http://bugs.php.net/?id=27934&edit=1
#27693 [Bgs]: imagettftext() coupled with imagecreatetruecolor() displays yellow fonts.
ID: 27693 Updated by: [EMAIL PROTECTED] Reported By: xavier dot blanchet at free dot fr Status: Bogus Bug Type: GD related Operating System: Linux PHP Version: 4.3.4 New Comment: "On Linux I cannot try the latest version before my hoster (OVH.com) has migrated :-( But as I have already mentionned the beta version PHP5 (http://240plan.ovh.net/test.beta )returns these same yellow fonts." "FreeType Version 1.3"... just forget it sorry. Then even when they upgrade it (in some servers, as I got one) it was the version "2.0", with which gd has some bugs with rotated text. I used a dedicated server there, so I upgraded myself to a recent version (2.1.7). Everything is fine since. So please keep this bug quiet and ask support questions on the right list (ie, php-install) or beg your ISP to upgrade to a recent freetype. hth pierre Previous Comments: [2004-04-15 20:35:16] cartoonlad at thesnakefarm dot com So for those of us who are muddling around with configuring php for the first time, what does that mean? Use --enable-gd-native-ttf in the configure? [2004-04-05 11:01:35] [EMAIL PROTECTED] ttf = freetype 1, old and buggy freetype = freetype 2, new, not buggy So just compile PHP against the newer version, not a bug -> bogus. [2004-04-05 09:56:18] xavier dot blanchet at free dot fr For me on Windows, it all works fine. On Linux I cannot try the latest version before my hoster (OVH.com) has migrated :-( But as I have already mentionned the beta version PHP5 ( http://240plan.ovh.net/test.beta )returns these same yellow fonts. However I noticed something interessting: each time i met someone in forums, newsgroups... experiencing the same problem, the FreeType Linkage in the phpinfo() was with "TTF Library". "with FreeType" is ok... [2004-04-03 09:51:00] [EMAIL PROTECTED] I can't reproduce either with PHP 4.2.6RC2-dev. I think the problem may be only with Unicode fonts, althought it works for me. [2004-04-01 11:56:52] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I am still unable to replicate the problem using the Arial ttf font avaliable on my system. Please include your configure line in your reply. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/27693 -- Edit this bug report at http://bugs.php.net/?id=27693&edit=1
#28263 [Opn->Fbk]: PNG image generation causes Segmentation Fault
ID: 28263 Updated by: [EMAIL PROTECTED] Reported By: Rich dot West at wesmo dot com -Status: Open +Status: Feedback Bug Type: GD related Operating System: Fedora Core 1 PHP Version: 4.3.6 -Assigned To: +Assigned To: pajoye New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Hello, Cannot reproduce, please try with a snapshot. I also use libpng-1.2.2 (which is available since this week through yum in fdc1). --Pierre Previous Comments: [2004-05-07 03:01:51] Rich dot West at wesmo dot com What version of libpng did you back down to? I have no problems trying that out. :) [2004-05-07 00:58:29] scottmacvicar at ntlworld dot com I had the same problem using the latest releases of libpng and had to go back to an older version. It would happen for any png image. Was using Red Hat Enterprise [2004-05-06 16:54:14] Rich dot West at wesmo dot com Any PNG image will do it. I woul attach it, but there's no interface here to attach the images that I tested with. [2004-05-06 14:40:31] [EMAIL PROTECTED] Please provide the source image. [2004-05-03 19:22:22] Rich dot West at wesmo dot com Description: After upgrading from PHP 4.3.3 to 4.3.5, and then again to 4.3.6, I discovered that image generation calls to create PNG files were producing zero length images. I dug through it further by testing with the CLI version of PHP, and it appears that if a PNG image is being created, the process with segfault. I was able to compile PHP 4.3.3 on this machine using the configure options below, and, after running the test script through php, it would properly output a PNG file. Using the same configure options for PHP 4.3.5 and PHP 4.3.6, the operation segfaults (and creates a core file) when creating a PNG file. It works just fine when creating a JPEG file. I can consistently get things to work for PHP 4.3.3 and I can consistently get it to NOT work for PHP 4.3.5 and PHP 4.3.6... Oh, and, yes, my GD and libpng10/libpng libraries are linked properly.. >From phpinfo(): './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-pdflib' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=sh
#28304 [Asn]: ImageFilter, no bounds check processing image per-pixel: creates a black border
ID: 28304 Updated by: [EMAIL PROTECTED] Reported By: ken at sonicwizardry dot com Status: Assigned Bug Type: GD related Operating System: Linux PHP Version: 5.0.0RC2 Assigned To: pajoye New Comment: the patch is ok, however I prefer to do the check only once outside the loops. Let me check first if it's possible for this filter. Which one are using? Pierre Previous Comments: [2004-05-06 18:50:38] ken at sonicwizardry dot com Description: Running ImageFilter on an image creates a black border around the edge because it references non-existing pixels off of the image (beyond image size). Bounds check/clamp added to convolution loop. Code DIFF is below: File path: ext/gd/libgd/gd.c 3607,3610c3607,3614 < pxl = f(srcback, x-(3>>1)+i, y-(3>>1)+j); < new_r += (float)gdImageRed(srcback, pxl) * filter[j][i]; < new_g += (float)gdImageGreen(srcback, pxl) * filter[j][i]; < new_b += (float)gdImageBlue(srcback, pxl) * filter[j][i]; --- > int ix = x-(3>>1)+i; > int iy = y-(3>>1)+j; > ix = (ix>=src->sx)?src->sx-1 : ((ix<0)?0:ix); > iy = (iy>=src->sy)?src->sy-1 : ((iy<0)?0:iy); > pxl = f(srcback, ix, iy); > new_r += (float)gdImageRed(srcback, pxl) * filter[j][i]; > new_g += (float)gdImageGreen(srcback, pxl) * filter[j][i]; > new_b += (float)gdImageBlue(srcback, pxl) * filter[j][i]; Hope this helps! -Ken Post Jr. -- Edit this bug report at http://bugs.php.net/?id=28304&edit=1
#28490 [Opn]: function ImageFillToBorder fails to fill the entire zone
ID: 28490
Updated by: [EMAIL PROTECTED]
Reported By: philippe dot nonn at capgemini dot com
Status: Open
Bug Type: GD related
Operating System: Windows XP / IIS
PHP Version: 4.3.6
New Comment:
Hello,
Are you talking about the lower left gap (at 50 deg)?
Anyway, please provide a script which only fills an area. You can
provide a link to the source and expected result images.
I feel like you should take a look here:
http://www.php.net/imagefilledarc
-- Pierre
Previous Comments:
[2004-05-22 20:39:17] philippe dot nonn at capgemini dot com
find above a script showing the part of pie not completely filled of
red color
Philippe
1)
{
//remplir les portions
$MidPoint = round((($EndDegrees - $StartDegrees)/2) +
$StartDegrees);
list($ArcX, $ArcY) = circle_point($MidPoint,
$ChartDiameter/2);
imagefilltoborder($image,
floor($ChartCenterX + $ArcX),
floor($ChartCenterY + $ArcY),
$CurrentColor,
$CurrentColor);
}
//afficher l'image
header("Content-type: image/jpeg");
imagejpeg($image);
php?>
[2004-05-22 17:40:03] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-05-22 17:00:42] philippe dot nonn at capgemini dot com
Description:
Using the las version of Graphical Library PHP_GD2 leads to display
images which are only partially filled when using the function
ImageFillToBorder.
It looks like only the upper part of the zone which should be filled
gets the selected color.
The problem doesn't appear when using le 4.3.5 version of php_gd2.
--
Edit this bug report at http://bugs.php.net/?id=28490&edit=1
#28490 [Opn->Bgs]: function ImageFillToBorder fails to fill the entire zone
ID: 28490
Updated by: [EMAIL PROTECTED]
Reported By: philippe dot nonn at capgemini dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: Windows XP / IIS
PHP Version: 4.3.6
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
It works as expected. I only looked the non filled arc and compare with
filled area. It is exactly what I expect.
--Pierre
Previous Comments:
[2004-05-22 23:52:04] [EMAIL PROTECTED]
Hello,
Are you talking about the lower left gap (at 50 deg)?
Anyway, please provide a script which only fills an area. You can
provide a link to the source and expected result images.
I feel like you should take a look here:
http://www.php.net/imagefilledarc
-- Pierre
[2004-05-22 20:39:17] philippe dot nonn at capgemini dot com
find above a script showing the part of pie not completely filled of
red color
Philippe
1)
{
//remplir les portions
$MidPoint = round((($EndDegrees - $StartDegrees)/2) +
$StartDegrees);
list($ArcX, $ArcY) = circle_point($MidPoint,
$ChartDiameter/2);
imagefilltoborder($image,
floor($ChartCenterX + $ArcX),
floor($ChartCenterY + $ArcY),
$CurrentColor,
$CurrentColor);
}
//afficher l'image
header("Content-type: image/jpeg");
imagejpeg($image);
php?>
[2004-05-22 17:40:03] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2004-05-22 17:00:42] philippe dot nonn at capgemini dot com
Description:
Using the las version of Graphical Library PHP_GD2 leads to display
images which are only partially filled when using the function
ImageFillToBorder.
It looks like only the upper part of the zone which should be filled
gets the selected color.
The problem doesn't appear when using le 4.3.5 version of php_gd2.
--
Edit this bug report at http://bugs.php.net/?id=28490&edit=1
#28506 [Opn->Csd]: imagearc() doesn't like negative value of the s parameter
ID: 28506
Updated by: [EMAIL PROTECTED]
Reported By: tony2001 at phpclub dot net
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: Linux 2.4.23
PHP Version: 5CVS-2004-05-24 (dev)
-Assigned To:
+Assigned To: pajoye
New Comment:
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.
while (s < 0) s += 360 is used now.
--Pierre
Previous Comments:
[2004-05-24 14:49:15] tony2001 at phpclub dot net
Description:
imagearc() draws broken arc, when using negative value as s parameter.
It could be GDlib bug, at least I found a couple of words in GD man:
http://www.boutell.com/gd/manual2.0.23.html about unspecified bugs in
gdImageArc().
Also, there can be simple workaround: just don't accept negative
values, reduce them to zero.
Reproduce code:
---
// result image is here: http://tony2001.phpclub.net/temp/imagearc.png
//
// create a 200*200 image
$img = imagecreate(200, 200);
// allocate some colors
$white = imagecolorallocate($img, 255, 255, 255);
$black = imagecolorallocate($img, 0, 50, 200);
// draw a white circle
imagearc($img, 100, 100, 150, 150, -1, 200, $black);
// output image in the browser
header("Content-type: image/png");
imagepng($img);
// free memory
imagedestroy($img);
Expected result:
a flat arc
Actual result:
--
a broken arc with some crosslines
--
Edit this bug report at http://bugs.php.net/?id=28506&edit=1
#25919 [Bgs]: Sometimes imagecreatefromjpeg stops
ID: 25919 Updated by: [EMAIL PROTECTED] Reported By: agnermadsen at hotmail dot com Status: Bogus Bug Type: GD related Operating System: FreeBSD PHP Version: 4.3.3 New Comment: > And since this is so well known, such an error > handling would maybe prevent all those bogus > bug reports in this area. And if everyone works with a proper error reporting mode and reads the logs, they may know what's going on. Nothing more can be done, the memory allocation is done by PHP (as near all allocations), the error is reported by PHP itself. --Pierre Previous Comments: [2004-08-10 23:08:09] stemplar444 at yahoo dot com My server hang, when the images contained more than 1'609'092 pixels. It was not a question of file size. I found this bug report and corrected my memory settings accordingly to fix this behavior. However, I disagree with [EMAIL PROTECTED], that this is no bug. In my opinion, proper API providers have to have a proper error handling. So in this case, the GD library or PHP needs to check for enough memory while executing a function. And since this is so well known, such an error handling would maybe prevent all those bogus bug reports in this area. simon. [2003-10-28 10:38:34] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It is quite likely you are reaching the memory limit and PHP terminates. Image manipulation is a very memory intensive process. I'd suggest raising the memory limit higher to something like 20 megabytes. [2003-10-24 05:40:12] agnermadsen at hotmail dot com memory_limit 8M http://www.ringsborg-madsen.dk/nytsite/phpinfo.php [2003-10-23 22:24:10] [EMAIL PROTECTED] What is your memory limit set to? You are probably reaching the memory limit and PHP terminates. [2003-10-23 03:47:06] agnermadsen at hotmail dot com Configure: './configure' '--enable-versioning' '--enable-memory-limit' '--with-layout=GNU' '--with-zlib-dir=/usr' '--disable-all' '--with-regex=php' '--disable-cli' '--with-apxs=/usr/local/sbin/apxs' '--with-bz2=/usr' '--enable-ctype' '--enable-exif' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--enable-gd-jis-conv' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-xpm-dir=/usr/local' '--with-imap=/usr/local' '--with-imap-ssl=/usr/local' '--with-mcrypt=/usr/local' '--with-mysql=/usr/local' '--enable-overload' '--with-pcre-regex=yes' '--enable-posix' '--enable-session' '--enable-sockets' '--enable-tokenizer' '--enable-xml' '--with-expat-dir=/usr/local' '--with-zlib=yes' '--prefix=/usr/local' 'i386-portbld-freebsd4.8' The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/25919 -- Edit this bug report at http://bugs.php.net/?id=25919&edit=1
