Bug #43475 [Asn]: Thick styled lines have scrambled patterns
Edit report at http://bugs.php.net/bug.php?id=43475edit=1 ID: 43475 User updated by:lbayuk at pobox dot com Reported by:lbayuk at pobox dot com Summary:Thick styled lines have scrambled patterns Status: Assigned Type: Bug Package:GD related Operating System: * PHP Version:5.2CVS-2008-10-30 Assigned To:pajoye Block user comment: N New Comment: OK, thanks, now I understand what it is doing. It is applying the pixels from the style across the width of the line first, then along the length second. But I don't agree that it is working correctly. I think the width and style should be independent, and I think the current behavior may be unintentional. Because gdImageSetPixel increments the style pointer for every pixel, then the order in which the higher-level drawing routines put down the pixels makes a difference in how the pattern is applied. Surely this cannot be useful. As an example, the problem you found with horizontal and vertical lines. If the width is 1, these are optimized as filled rectangles. But filled rectangles with IMG_COLOR_STYLED are unpredictable, because the result depends on the remainder when dividing the rectangle width by the style array size. (Try drawing 2 filled rectangles with an IMG_COLOR_STYLED pattern, where 1 rectangle is 1 pixel wider than the other. They will look very different.) I would like to hear what the PHP GD maintainer thinks about this. (FYI, now using PHP-5.3.3 with same results) Previous Comments: [2010-08-02 21:55:39] php at imperium dot be Lines *do* have the expected style, *EXCEPT* when they are at a 0 or 180 degree angle (e.g. x1==x2). That is where the 'bug' is at. This is probably because imageline tries to be more efficient than it should be, drawing a fast rectangle instead of a thick line. In any case, the style pattern is applied towards the flow of the line instead of linear. This is the correct approach imho and should not be changed. To achieve the same style pattern with a line twice as thick you should double your imagesetstyle as well. E.G. in your test case, 16+4+8+4 for thickness 1 would become 32+8+16+8 for thickness 2. When you adjust your test case like this, you will see that all works as expected except for horizontal lines. Thus, GD maintainer, please adjust the inner workings of imageline so it won't paint a rectangle instead of a thick line (at least not for thickness1 or when using styled lines). jacQues [2008-10-30 17:03:59] j...@php.net Assigned to the GD maintainer. [2008-10-27 01:50:09] lbayuk at pobox dot com I tried php5.2-200810262330 (PHP 5.2.7RC3-dev), using bundled gd. There is no difference. The problem is still there, and the image is the same as in 5.2.6. [2008-10-24 16:01:49] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use the bundled GD library! [2007-12-02 02:10:59] lbayuk at pobox dot com Description: Styled lines with thickness greater than 1 are not drawn correctly. The style pattern is not visible, and the lines have a 'scrambled' or 'plaid' appearance. Reproduce code: --- ?php $img = imagecreate(800,800); $bg = ImageColorAllocate($img, 255, 255, 255); $fg = ImageColorAllocate($img, 0, 0, 0); $style = array(); # Make a pattern of 16 on, 4 off, 8 on, 4 off for ($i = 0; $i 16; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; for ($i = 0; $i 8; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; ImageSetStyle($img, $style); ImageSetThickness($img, 1); ImagePolygon($img,array(50,250,550,250,550,750),3,IMG_COLOR_STYLED); ImageSetThickness($img, 2); ImagePolygon($img,array(100,200,600,200,600,700),3,IMG_COLOR_STYLED); ImageSetThickness($img, 4); ImagePolygon($img,array(150,150,650,150,650,650),3,IMG_COLOR_STYLED); ImageSetThickness($img, 6); ImagePolygon($img,array(200,100,700,100, 700,600),3,IMG_COLOR_STYLED); ImagePng($img); Expected result: The output of the script is a PNG file. The image should contain 4 triangles drawn with a styled line (16 pixels on, 4 off, 8 on, 4 off). From lower left to upper right, the triangles are drawn with line thickness 1, 2, 4, and 6 respectively. The styled pattern should be visible in all of the triangles. Actual result: -- The triangle with thickness 1 is correctly drawn. The other triangles are not correctly drawn
#48732 [Com]: TTF Bounding box wrong for letters below baseline
ID: 48732
Comment by: lbayuk at pobox dot com
Reported By: sta at netimage dot dk
Status: Open
Bug Type: GD related
Operating System: FreeBSD 7.1
PHP Version: 5.2.10
New Comment:
Duplicated in PHP-5.2.10 and also PHP-5.3.0. The descenders are being
excluded from the bounding box, at all angles. (Sigh. I was the one who
opened bug #43073 for rotated bounding boxes. My mistake for not
including characters with descenders in the original reproduce code.)
Previous Comments:
[2009-07-03 11:02:32] sta at netimage dot dk
The fix for bug #48555 did not solve this problem - bug still open.
The test string should probably be changed to
line1\nQÅDFqypådg!()/\%#9619; so the new line problem from #48555 is
checked too.
[2009-06-30 07:42:54] sta at netimage dot dk
To images, one rendered with PHP 5.2.9, the other with 5.2.10.
http://php.thing.dev.netimage.dk/48732_5_2_9.png
http://php.thing.dev.netimage.dk/48732_5_2_10.png
Both rendered on FreeBSD with freetype2-2.3.9_1 from ports.
[2009-06-30 07:31:48] sta at netimage dot dk
Description:
Bug #43073 fixed the bounding box for rotated texts.
Unfortunately the test case only used upper case ABCDEF for the test,
an not any letters that protrude below the text baseline.
Hence the returned bounding box is now wrong for text like ABCQÅqyp.
The code below is directly from bug #43073, only the font, demo-text
and font size has been changed.
Reproduce code:
---
?php
$font = '/dana/data/ni_lib/ni_shop/fonts/CONGSEB.TTF'; # Full path to
any TTF Font
$delta_t = 360.0 / 16; # Make 16 steps around
$g = imagecreate(800, 800);
$bgnd = imagecolorallocate($g, 255, 255, 255);
$black = imagecolorallocate($g, 0, 0, 0);
$x = 100;
$y = 0;
$cos_t = cos(deg2rad($delta_t));
$sin_t = sin(deg2rad($delta_t));
for($angle = 0.0; $angle 360.0; $angle += $delta_t) {
$bbox = imagettftext($g, 20, $angle, 400 + $x, 400 + $y, $black,
$font, 'QÅDFqypådg!()/\%#9619;');
imagepolygon($g, $bbox, 4, $black);
imagefilledellipse($g, $bbox [0], $bbox [1], 8, 8, $black);
$temp = $cos_t * $x + $sin_t * $y;
$y = $cos_t * $y - $sin_t * $x;
$x = $temp;
}
header( Content-type: image/png);
imagepng($g);
Expected result:
That the rectangles contain the entire text, including the parts that
protrude below the text baseline.
Actual result:
--
Lower part of eg q are outside the box.
Images will be attached in a second.
--
Edit this bug report at http://bugs.php.net/?id=48732edit=1
#43073 [Fbk-Opn]: TrueType bounding box is wrong for angle0
ID: 43073
User updated by: lbayuk at pobox dot com
Reported By: lbayuk at pobox dot com
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: Linux
-PHP Version: 5.2.4
+PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
I tried php5.2-200811022130 (PHP 5.2.7RC3-dev).
The problem is still there, and the image is identical to PHP-5.2.6.
(I was using 5.2.4 when I originally submitted this report, so I
changed the version in the report to 5.2.6).
Previous Comments:
[2008-11-02 13:07:53] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2007-10-23 00:18:33] lbayuk at pobox dot com
Description:
The bounding box returned from imagettfbbox() and imagettftext() is
incorrect for anything except horizontal text at 0 degrees. For all
other angles, the text is partially or completely outside the returned
bounding box. (Yes, somebody reported the same problem in #37730, but
that was marked no feedback and is not getting any attention. Could
someone please-please look at this issue?) The PHP script below
demonstrates. Using the bundled GD library, and any TrueType font.
Change $font to point to any TrueType font file you have.
Run via PHP CLI, sending out to filename.png and view, or access via
browser.
I wrote an equivalent C program with gd-2.0.35 (Slackware 12.0 Linux
distribution), and the bounding boxes are correct. So there is probably
something wrong in the GD library bundled with PHP.
Reproduce code:
---
?php
$font = '/usr/share/fonts/TTF/luximr.ttf'; # Full path to any TTF Font
$delta_t = 360.0 / 16; # Make 16 steps around
$g = imagecreate(800, 800);
$bgnd = imagecolorallocate($g, 255, 255, 255);
$black = imagecolorallocate($g, 0, 0, 0);
$x = 100;
$y = 0;
$cos_t = cos(deg2rad($delta_t));
$sin_t = sin(deg2rad($delta_t));
for ($angle = 0.0; $angle 360.0; $angle += $delta_t) {
$bbox = imagettftext($g, 24, $angle, 400+$x, 400+$y, $black, $font,
'ABCDEF');
imagepolygon($g, $bbox, 4, $black);
imagefilledellipse($g, $bbox[0], $bbox[1], 8, 8, $black);
$temp = $cos_t * $x + $sin_t * $y;
$y= $cos_t * $y - $sin_t * $x;
$x= $temp;
}
header(Content-type: image/png);
imagepng($g);
Expected result:
In the image output: For each angle of text, the box should enclose the
text, with the dot to the lower left (relative to the text baseline) of
the first character in the string.
Actual result:
--
The bounding box for 0 degree text is correct. All the others are off
by different amounts. Worst is the text between 180 and 270 degrees,
where the text is completely outside the bounding box.
--
Edit this bug report at http://bugs.php.net/?id=43073edit=1
#43475 [Fbk-Opn]: Thick styled lines have scrambled patterns
ID: 43475 User updated by: lbayuk at pobox dot com Reported By: lbayuk at pobox dot com -Status: Feedback +Status: Open Bug Type: GD related Operating System: Linux -PHP Version: 5.2.5 +PHP Version: 5.2.6 New Comment: I tried php5.2-200810262330 (PHP 5.2.7RC3-dev), using bundled gd. There is no difference. The problem is still there, and the image is the same as in 5.2.6. Previous Comments: [2008-10-24 16:01:49] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ And use the bundled GD library! [2007-12-02 02:10:59] lbayuk at pobox dot com Description: Styled lines with thickness greater than 1 are not drawn correctly. The style pattern is not visible, and the lines have a 'scrambled' or 'plaid' appearance. Reproduce code: --- ?php $img = imagecreate(800,800); $bg = ImageColorAllocate($img, 255, 255, 255); $fg = ImageColorAllocate($img, 0, 0, 0); $style = array(); # Make a pattern of 16 on, 4 off, 8 on, 4 off for ($i = 0; $i 16; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; for ($i = 0; $i 8; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; ImageSetStyle($img, $style); ImageSetThickness($img, 1); ImagePolygon($img,array(50,250,550,250,550,750),3,IMG_COLOR_STYLED); ImageSetThickness($img, 2); ImagePolygon($img,array(100,200,600,200,600,700),3,IMG_COLOR_STYLED); ImageSetThickness($img, 4); ImagePolygon($img,array(150,150,650,150,650,650),3,IMG_COLOR_STYLED); ImageSetThickness($img, 6); ImagePolygon($img,array(200,100,700,100, 700,600),3,IMG_COLOR_STYLED); ImagePng($img); Expected result: The output of the script is a PNG file. The image should contain 4 triangles drawn with a styled line (16 pixels on, 4 off, 8 on, 4 off). From lower left to upper right, the triangles are drawn with line thickness 1, 2, 4, and 6 respectively. The styled pattern should be visible in all of the triangles. Actual result: -- The triangle with thickness 1 is correctly drawn. The other triangles are not correctly drawn with the desired line style, although the diagonal part of the thickness 2 triangle looks correct. The other lines appear to have a 'plaid' pattern. Using a 4x screen magnifier, I can see that the multiple parallel lines which make up the thick lines each have the correct style, but the patterns in these lines are offset relative to each other, so the overall appearance does not reflect the desired style. -- Edit this bug report at http://bugs.php.net/?id=43475edit=1
#46145 [Opn]: printf %e format should make 2 digit exponent
ID: 46145
User updated by: lbayuk at pobox dot com
Reported By: lbayuk at pobox dot com
Status: Open
Bug Type: Strings related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
After taking a look at your patch, approximately:
/*
* Make sure the exponent has at least 2 digits
*/
+if (t_len = 1) {
+ *s++ = '0';
+}
while (t_len--) {
I got curious, since the code you added is described by the existing
comment. So I checked back through CVS and sure enough similar code was
there a while ago and was removed. It was:
if (t_len == 1)
*s++ = '0';
So it looks like the 2-digit minimum exponent code was *removed*.
Certainly we would not want to put the code back in until we determine
why it came out... perhaps there was a good reason. I haven't yet
located the exact file version where the change was made.
Previous Comments:
[2008-09-28 23:07:03] ilia dot cheishvili at gmail dot com
The patch to fix this is here, along with all of the unit tests that
had to be modified to take the new, correct behavior into account:
http://pastebin.com/f641cf6fd
[2008-09-21 19:44:25] lbayuk at pobox dot com
Description:
PHP printf, sprintf, and fprintf with %e scientific notation produce a
1 digit exponent for values less than 1e10. Other implementation of
functions by the same name produce a minimum of 2 digits in the
exponent, as the C standard requires. Although it can be argued that PHP
is not bound by other standards, the following comment in
main/snprintf.c function php_conv_fp() [line 545] leads one to believe
this is a PHP bug:
/*
* Make sure the exponent has at least 2 digits
*/
Reproduce code:
---
?php
printf(%8.2e\n, 100);
Expected result:
1.00e+06
Actual result:
--
space1.00e+6
--
Edit this bug report at http://bugs.php.net/?id=46145edit=1
#46145 [NEW]: printf %e format should make 2 digit exponent
From: lbayuk at pobox dot com Operating system: Linux PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: printf %e format should make 2 digit exponent Description: PHP printf, sprintf, and fprintf with %e scientific notation produce a 1 digit exponent for values less than 1e10. Other implementation of functions by the same name produce a minimum of 2 digits in the exponent, as the C standard requires. Although it can be argued that PHP is not bound by other standards, the following comment in main/snprintf.c function php_conv_fp() [line 545] leads one to believe this is a PHP bug: /* * Make sure the exponent has at least 2 digits */ Reproduce code: --- ?php printf(%8.2e\n, 100); Expected result: 1.00e+06 Actual result: -- space1.00e+6 -- Edit bug report at http://bugs.php.net/?id=46145edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46145r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46145r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46145r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46145r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46145r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46145r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46145r=needscript Try newer version:http://bugs.php.net/fix.php?id=46145r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46145r=support Expected behavior:http://bugs.php.net/fix.php?id=46145r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46145r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46145r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46145r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46145r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46145r=dst IIS Stability:http://bugs.php.net/fix.php?id=46145r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46145r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46145r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46145r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46145r=mysqlcfg
#43475 [NEW]: Thick styled lines have scrambled patterns
From: lbayuk at pobox dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: GD related Bug description: Thick styled lines have scrambled patterns Description: Styled lines with thickness greater than 1 are not drawn correctly. The style pattern is not visible, and the lines have a 'scrambled' or 'plaid' appearance. Reproduce code: --- ?php $img = imagecreate(800,800); $bg = ImageColorAllocate($img, 255, 255, 255); $fg = ImageColorAllocate($img, 0, 0, 0); $style = array(); # Make a pattern of 16 on, 4 off, 8 on, 4 off for ($i = 0; $i 16; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; for ($i = 0; $i 8; $i++) $style[] = $fg; for ($i = 0; $i 4; $i++) $style[] = IMG_COLOR_TRANSPARENT; ImageSetStyle($img, $style); ImageSetThickness($img, 1); ImagePolygon($img,array(50,250,550,250,550,750),3,IMG_COLOR_STYLED); ImageSetThickness($img, 2); ImagePolygon($img,array(100,200,600,200,600,700),3,IMG_COLOR_STYLED); ImageSetThickness($img, 4); ImagePolygon($img,array(150,150,650,150,650,650),3,IMG_COLOR_STYLED); ImageSetThickness($img, 6); ImagePolygon($img,array(200,100,700,100, 700,600),3,IMG_COLOR_STYLED); ImagePng($img); Expected result: The output of the script is a PNG file. The image should contain 4 triangles drawn with a styled line (16 pixels on, 4 off, 8 on, 4 off). From lower left to upper right, the triangles are drawn with line thickness 1, 2, 4, and 6 respectively. The styled pattern should be visible in all of the triangles. Actual result: -- The triangle with thickness 1 is correctly drawn. The other triangles are not correctly drawn with the desired line style, although the diagonal part of the thickness 2 triangle looks correct. The other lines appear to have a 'plaid' pattern. Using a 4x screen magnifier, I can see that the multiple parallel lines which make up the thick lines each have the correct style, but the patterns in these lines are offset relative to each other, so the overall appearance does not reflect the desired style. -- Edit bug report at http://bugs.php.net/?id=43475edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43475r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43475r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43475r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43475r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43475r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43475r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43475r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43475r=needscript Try newer version:http://bugs.php.net/fix.php?id=43475r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43475r=support Expected behavior:http://bugs.php.net/fix.php?id=43475r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43475r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43475r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43475r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43475r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43475r=dst IIS Stability:http://bugs.php.net/fix.php?id=43475r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43475r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43475r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43475r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43475r=mysqlcfg
#43283 [NEW]: CLI does not define STDOUT/STDERR with stdin script
From: lbayuk at pobox dot com Operating system: Linux PHP version: 5.2.5 PHP Bug Type: CGI related Bug description: CLI does not define STDOUT/STDERR with stdin script Description: When using the PHP CLI executable, the script can be named on the command line, or fed to PHP through standard input. If using standard input, the file constants STDIN, STDOUT, and STDERR are undefined. I can understand not defining STDIN, since the script is read from there, but why are STDOUT and STDERR not defined? Reproduce code: --- ?php fwrite(STDOUT, Hello, standard output\n); fwrite(STDERR, Hello, standard error\n); Expected result: Written to stdout: Hello, standard output Written to stderr: Hello, standard error Actual result: -- When run as: $ php nostd.php Works as expected. When run as: $ php nostd.php This output: PHP Notice: Use of undefined constant STDOUT - assumed 'STDOUT' in ... PHP Warning: fwrite(): supplied argument is not a valid stream resource in... PHP Notice: Use of undefined constant STDERR - assumed 'STDERR' in ... PHP Warning: fwrite(): supplied argument is not a valid stream resource in ... -- Edit bug report at http://bugs.php.net/?id=43283edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43283r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43283r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43283r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43283r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43283r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43283r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43283r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43283r=needscript Try newer version:http://bugs.php.net/fix.php?id=43283r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43283r=support Expected behavior:http://bugs.php.net/fix.php?id=43283r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43283r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43283r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43283r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43283r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43283r=dst IIS Stability:http://bugs.php.net/fix.php?id=43283r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43283r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43283r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43283r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43283r=mysqlcfg
#43073 [NEW]: TrueType bounding box is wrong for angle0
From: lbayuk at pobox dot com
Operating system: Linux
PHP version: 5.2.4
PHP Bug Type: GD related
Bug description: TrueType bounding box is wrong for angle0
Description:
The bounding box returned from imagettfbbox() and imagettftext() is
incorrect for anything except horizontal text at 0 degrees. For all other
angles, the text is partially or completely outside the returned bounding
box. (Yes, somebody reported the same problem in #37730, but that was
marked no feedback and is not getting any attention. Could someone
please-please look at this issue?) The PHP script below demonstrates. Using
the bundled GD library, and any TrueType font.
Change $font to point to any TrueType font file you have.
Run via PHP CLI, sending out to filename.png and view, or access via
browser.
I wrote an equivalent C program with gd-2.0.35 (Slackware 12.0 Linux
distribution), and the bounding boxes are correct. So there is probably
something wrong in the GD library bundled with PHP.
Reproduce code:
---
?php
$font = '/usr/share/fonts/TTF/luximr.ttf'; # Full path to any TTF Font
$delta_t = 360.0 / 16; # Make 16 steps around
$g = imagecreate(800, 800);
$bgnd = imagecolorallocate($g, 255, 255, 255);
$black = imagecolorallocate($g, 0, 0, 0);
$x = 100;
$y = 0;
$cos_t = cos(deg2rad($delta_t));
$sin_t = sin(deg2rad($delta_t));
for ($angle = 0.0; $angle 360.0; $angle += $delta_t) {
$bbox = imagettftext($g, 24, $angle, 400+$x, 400+$y, $black, $font,
'ABCDEF');
imagepolygon($g, $bbox, 4, $black);
imagefilledellipse($g, $bbox[0], $bbox[1], 8, 8, $black);
$temp = $cos_t * $x + $sin_t * $y;
$y= $cos_t * $y - $sin_t * $x;
$x= $temp;
}
header(Content-type: image/png);
imagepng($g);
Expected result:
In the image output: For each angle of text, the box should enclose the
text, with the dot to the lower left (relative to the text baseline) of the
first character in the string.
Actual result:
--
The bounding box for 0 degree text is correct. All the others are off by
different amounts. Worst is the text between 180 and 270 degrees, where the
text is completely outside the bounding box.
--
Edit bug report at http://bugs.php.net/?id=43073edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43073r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43073r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43073r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43073r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43073r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43073r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43073r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43073r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43073r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43073r=support
Expected behavior:http://bugs.php.net/fix.php?id=43073r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43073r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43073r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43073r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43073r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43073r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43073r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43073r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43073r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43073r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43073r=mysqlcfg
#37730 [Com]: ImageTTFText ImageTTFBBox don't give accurate rectangle with angle
ID: 37730 Comment by: lbayuk at pobox dot com Reported By: marc dot lazzaro at st dot com Status: No Feedback Bug Type: GD related Operating System: Win XP PHP Version: 5.1.4 Assigned To: pajoye New Comment: I am also finding that the TrueType font bounding box from ImageTTFBBox and ImageTTFText seems to be wrong for text at angles other than 0 degrees. Using PHP-5.2.4 on Linux. My test script just draws the returned bounding box for text and angles from 0 to 360. It shows that for text at 0 degrees, the box encloses the text, but for all other angles the box is off by different amounts. The worst case is for text between 180 and 270 degrees, where the text is completely outside the bounding box. My test script is about 50 lines long, and I would be happy to post or mail it but I'm not sure what is correct. Let's not abandon this bug report until we figure out whether PHP is at fault or we are using it wrong. Previous Comments: [2007-03-09 01:00:00] 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. [2007-03-01 12:00:29] hopka at hopka dot net The font is standard Arial, the ttf i use is here: http://hopka.net/Arial.ttf However, i did try other fonts and i could not find any font that produced different results. [2007-03-01 11:45:44] [EMAIL PROTECTED] so i don't see how i should rotate the offset to get the correct bounding box. Your script is wrong, you add 100 to each vertex, no matter where they are. The result rectangle is then drawn at the wrong place. About the offset pixel, what I asked here remains. Please provide the font as well. [2007-03-01 11:40:15] hopka at hopka dot net If i draw the box that imagettftext (sorry, did not try that before) returns without modifying the coordinates, it is almost (1 pixel off) the same as the box i get after adding 100 to each coordinate of imagettfbbox' return value. That would mean that either imagettftext is also wrong (because it produces the same results as my script) or that one would also have to modify the coordinates returned by imagettftext. Also, the rectangles returned by both functions are already rotated, so i don't see how i should rotate the offset to get the correct bounding box. [2007-03-01 00:14:13] [EMAIL PROTECTED] I made a little demonstration script (includes source + phpinfo): http://hopka.net/imagettfbbox.php5; Your script is wrong, you forgot that each position is relative to the origin of the text. Adding 100 to each of them is not correct. You have to rotate the offset. 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/37730 -- Edit this bug report at http://bugs.php.net/?id=37730edit=1
#41195 [Opn]: Indexing non-array should raise notice
ID: 41195 User updated by: lbayuk at pobox dot com Reported By: lbayuk at pobox dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.2.1 New Comment: OK, so we're back at Feature/Change Request. Except on further thought I like the way it works and would prefer it not change. I just want clarification of what is supposed to happen when you apply square brackets to a non-array. If it is working as intended (silenty returns NULL), please document it. If it isn't working as intended, please fix it. Previous Comments: [2007-05-02 10:35:40] [EMAIL PROTECTED] Change requests belong to the Feature/Change Request category. Reclassified. [2007-05-01 01:32:05] lbayuk at pobox dot com Changed category... I thought I put it in as Arrays related, but I guess I missed and it ended up as Feature/Change Request. To me, this is either a bug, or a documentation improvement request, not a feature request. [2007-04-26 01:38:31] lbayuk at pobox dot com Description: If I index a scalar or NULL variable as if it were an array, I get NULL back with no warning or notice. This is true for any index value, including 0. I expected an Undefined offset or incorrect type message. The manual says an integer variable = n will convert to array(0=$n); that works on casting to array but not on indexing. Reproduce code: --- ?php error_reporting(E_ALL+E_STRICT); $arry = array(1=1); $notarry = NULL; $intvar = 123; echo 1. arry[1] = . $arry[1] . \n; echo 2. arry[2] = . $arry[2] . \n; echo 3. intvar[0] = . $intvar[0] . \n; echo 4. intvar[1] = . $intvar[1] . \n; echo 5. notarry[1] = . $notarry[1] . \n; Expected result: Notice: Undefined offset (or incorrect type) for (2), (3), (4), and (5). Or maybe (3) should echo 123 via implicit cast. But only (2) raises a Notice; the others just echo NULL. Actual result: -- 1. arry[1] = 1 Notice: Undefined offset: 2 in /a5/home/ljb/lang/php/p.php on line 7 2. arry[2] = 3. intvar[0] = 4. intvar[1] = 5. notarry[1] = -- Edit this bug report at http://bugs.php.net/?id=41195edit=1
#41195 [Opn]: Indexing non-array should raise notice
ID: 41195 User updated by: lbayuk at pobox dot com Reported By: lbayuk at pobox dot com Status: Open -Bug Type: Feature/Change Request +Bug Type: Arrays related Operating System: Linux PHP Version: 5.2.1 New Comment: Changed category... I thought I put it in as Arrays related, but I guess I missed and it ended up as Feature/Change Request. To me, this is either a bug, or a documentation improvement request, not a feature request. Previous Comments: [2007-04-26 01:38:31] lbayuk at pobox dot com Description: If I index a scalar or NULL variable as if it were an array, I get NULL back with no warning or notice. This is true for any index value, including 0. I expected an Undefined offset or incorrect type message. The manual says an integer variable = n will convert to array(0=$n); that works on casting to array but not on indexing. Reproduce code: --- ?php error_reporting(E_ALL+E_STRICT); $arry = array(1=1); $notarry = NULL; $intvar = 123; echo 1. arry[1] = . $arry[1] . \n; echo 2. arry[2] = . $arry[2] . \n; echo 3. intvar[0] = . $intvar[0] . \n; echo 4. intvar[1] = . $intvar[1] . \n; echo 5. notarry[1] = . $notarry[1] . \n; Expected result: Notice: Undefined offset (or incorrect type) for (2), (3), (4), and (5). Or maybe (3) should echo 123 via implicit cast. But only (2) raises a Notice; the others just echo NULL. Actual result: -- 1. arry[1] = 1 Notice: Undefined offset: 2 in /a5/home/ljb/lang/php/p.php on line 7 2. arry[2] = 3. intvar[0] = 4. intvar[1] = 5. notarry[1] = -- Edit this bug report at http://bugs.php.net/?id=41195edit=1
#41195 [NEW]: Indexing non-array should raise notice
From: lbayuk at pobox dot com Operating system: Linux PHP version: 5.2.1 PHP Bug Type: Arrays related Bug description: Indexing non-array should raise notice Description: If I index a scalar or NULL variable as if it were an array, I get NULL back with no warning or notice. This is true for any index value, including 0. I expected an Undefined offset or incorrect type message. The manual says an integer variable = n will convert to array(0=$n); that works on casting to array but not on indexing. Reproduce code: --- ?php error_reporting(E_ALL+E_STRICT); $arry = array(1=1); $notarry = NULL; $intvar = 123; echo 1. arry[1] = . $arry[1] . \n; echo 2. arry[2] = . $arry[2] . \n; echo 3. intvar[0] = . $intvar[0] . \n; echo 4. intvar[1] = . $intvar[1] . \n; echo 5. notarry[1] = . $notarry[1] . \n; Expected result: Notice: Undefined offset (or incorrect type) for (2), (3), (4), and (5). Or maybe (3) should echo 123 via implicit cast. But only (2) raises a Notice; the others just echo NULL. Actual result: -- 1. arry[1] = 1 Notice: Undefined offset: 2 in /a5/home/ljb/lang/php/p.php on line 7 2. arry[2] = 3. intvar[0] = 4. intvar[1] = 5. notarry[1] = -- Edit bug report at http://bugs.php.net/?id=41195edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41195r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41195r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41195r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41195r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41195r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41195r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41195r=needscript Try newer version:http://bugs.php.net/fix.php?id=41195r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41195r=support Expected behavior:http://bugs.php.net/fix.php?id=41195r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41195r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41195r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41195r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41195r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41195r=dst IIS Stability:http://bugs.php.net/fix.php?id=41195r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41195r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41195r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41195r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41195r=mysqlcfg
