I’m running the following script:
php -r '
$text = "2020-12-23T13:25:44Z";
$font = "Inconsolatazi4varl_qu-Regular.otf"; // attached
$fontsize = 14;
$bbox = imageftbbox($fontsize, 0, $font, $text);
$ascender = abs($bbox[7]) /* +1 */;
$descender = abs($bbox[1]);
$size_w = abs($bbox[0]) + abs($bbox[2]);
$size_h = $ascender + $descender;
$x = -$bbox[0];
$y = $ascender;
//print_r(array("bbox"=>$bbox,"ascender"=>$ascender,"descender"=>$descender,"size_w"=>$size_w,"size_h"=>$size_h,"x"=>$x,"y"=>$y));
$im = imagecreatetruecolor($size_w, $size_h);
$bgcol = imagecolorallocate($im, 0xDD, 0xDD, 0xDD);
$fgcol = imagecolorallocate($im, 0x00, 0x00, 0x23);
imagefilledrectangle($im, 0, 0, $size_w - 1, $size_h - 1, $bgcol);
imagefttext($im, $fontsize, 0, $x, $y, $fgcol, $font, $text);
imagetruecolortopalette($im, FALSE, 256);
imagepng($im, NULL, 9);
' >TS.png
The values I get are:
Array
(
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)
[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)
However, these are too small. At least the upper horizontal bar
of the ‘T’ is completely cut off, and (as can be seen when the
/* +1 */ is uncommented) *all* digits have *significant* black
in the topmost line (ascender=12).
Adding 2 to both descender and ascender shows that that’s it.
I suspect rounding to be at fault: the bounding box is most
likely provided via floating point, then cut down to integers.
When dealing with bounding boxen, the correct rounding method
to use is “away from 0”, so that fractional pixels will also
be present.
Dixi quod…
For comparison, php7.3-gd (7.3.19-1~deb10u1) on buster/i386 gives me:
Array
(
[bbox] => Array
(
[0] => 0
[1] => 1
[2] => 187
[3] => 1
[4] => 187
[5] => -13
[6] => 0
[7] => -13
)
[ascender] => 13
[descender] => 1
[size_w] => 187
[size_h] => 14
[x] => 0
[y] => 13
)
This is more in the expected range.
That being said, php7.3-gd:x32 (7.3.15-3) on sid gives me…
Array
(
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)
[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)
… which matches php7.4, so this could also a problem
in a different package in sid, or fixed later in 7.3…
(php7.0 7.0.32-1 and php7.2 7.2.11-3 behave the same, too.)
bye,
//mirabilos
Dear submitter, as the package php8.0 has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/997821 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Scott Kitterman (the ftpmaster behind the curtain)
(pbuild3309-sid/i386)root@tglase:/tmp# php x.php
Array
(
[V] => 8.1.0
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)
[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)
Still same as 8.0 and 7.4(bullseye):
$ php x.php
Array
(
[V] => 7.4.25
[bbox] => Array
(
[0] => 1
[1] => 0
[2] => 185
[3] => 0
[4] => 185
[5] => -11
[6] => 1
[7] => -11
)
[ascender] => 11
[descender] => 0
[size_w] => 186
[size_h] => 11
[x] => -1
[y] => 11
)
For comparison, in buster the values are as expected:
$ php x.php
Array
(
[V] => 7.3.31-1~deb10u1
[bbox] => Array
(
[0] => 0
[1] => 1
[2] => 187
[3] => 1
[4] => 187
[5] => -13
[6] => 0
[7] => -13
)
[ascender] => 13
[descender] => 1
[size_w] => 187
[size_h] => 14
[x] => 0
[y] => 13
)
Hi, it would probably have been better to reassign all (relevant) bugreports to the equivalent 8.1 packages first; this is probably something the PHP maintainers ought to have done, as closing all bugs on package removal is normal ftpmasters procedure. Maybe next time? ☻ bye, //mirabilos
reassign 980759 libgd3
# version in buster
notfound 980759 2.2.5-5.2
# version in bullseye, bookworm/testing, sid
found 980759 2.3.0-2
tags 980759 + bullseye bookworm sid
forwarded 980759 https://github.com/libgd/libgd/issues/814
affects 980759 php7.4-gd
affects 980759 php8.0-gd
affects 980759 php8.1-gd
thanks
Hi,
upstream had a good idea to try. And indeed:
Installing php7.3-{cli,gd} on bullseye (after removing the Breaks from
php-common the maintainer added just to make it harder to coinstall the
versions) yields the same broken values…
$ php7.3 x.php |fgrep scender
[ascender] => 11
[descender] => 0
… while LD_PRELOADing the exact library from buster
libgd3_2.2.5-5.2_amd64.deb, ceteris paribus, gives the correct values:
$ LD_PRELOAD=$PWD/libgd.so.3.0.5 php7.3 x.php |fgrep scender
[ascender] => 13
[descender] => 1
$ LD_PRELOAD=$PWD/libgd.so.3.0.5 php7.4 x.php |fgrep scender
[ascender] => 13
[descender] => 1
This makes it 100% clear that libgd3 is at fault, neither PHP nor any of
libgd3’s or PHP’s dependencies. Reassigning.
bye,
//mirabilos
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc