Edit report at https://bugs.php.net/bug.php?id=51135&edit=1
ID: 51135
Comment by: sharon_correll at sil dot org
Reported by: sharon_correll at sil dot org
Summary: imagettftext does not work for characters > 99999
Status: Suspended
Type: Bug
Package: GD related
Operating System: Windows Vista
PHP Version: 5.2.12
Block user comment: N
Private report: N
New Comment:
I'm currently using PHP 8.
Previous Comments:
------------------------------------------------------------------------
[2023-07-11 13:53:33] sharon_correll at sil dot org
Does anybody know the status of this issue? There are indications that the underlying libgd bug was
addressed, but it still doesn't appear to work in PHP.
------------------------------------------------------------------------
[2016-08-22 14:32:08] cmb@php.net
Thanks for the analysis, the patch and the archive, Adam!
I can confirm that the patch correctly solves the issues with
decoding large numeric entities.
The non BMP characters are not rendered, because
FT_Get_Char_Index() returns 0, what corresponds to the missing
glyph. That is because the font file contains 4 charmaps, but GD
currently always uses the first charmap, and the non BMP
characters are contained in charmap 3. Switching to charmap 3 via
FT_Set_Charmap() delivers the same result as mockup.png.
I'll have to investigate on how to dynamically select the
appropriate charmap.
Anyhow, this is actually a libgd issue, and so I'm suspending this
ticket until <https://github.com/libgd/libgd/issues/185>
is
resolved.
------------------------------------------------------------------------
[2010-11-04 00:11:05] sharon_correll at sil dot org
The responses to this report seem to imply that ImageTtfText WIIL work correctly for characters in
the range U+10000 - U+1869F (65536 - 99999). However, this does not seem to be the case. When I call
it with "𐀁" (U+10001), it produces an "missing" glyph, even using a
font that contains the character (CODE2001.ttf).
This is a slightly different bug than what I originally reported, but I would guess it is related.
Is it a known problem?
------------------------------------------------------------------------
[2010-03-05 17:24:42] aharvey@php.net
The following patch has been added/updated:
Patch Name: bundled-libgd-non-bmp-entities
Revision: 1267806282
URL: http://bugs.php.net/patch-display.php?bug=51135&patch=bundled-libgd-non-bmp-entities&revision=1267806282&display=1
------------------------------------------------------------------------
[2010-03-05 17:23:44] aharvey@php.net
This is still happening with an up-to-date PHP_5_3 SVN checkout using the bundled libgd. I've
only tested it on Linux, but the relevant code in libgd/gdft.c doesn't appear to be platform
specific.
It's exactly what the libgd bug indicates: gdTcl_UtfToUniChar() simply stops looking for the
end of a numeric or hexadecimal entity reference two characters earlier than it should to cover all
possible Unicode characters out to Plane 16. The patch for libgd is trivial, and I'll attach it
after I post this comment.
I've created a tarball containing a test script, a font containing Plane 1 characters (which is
valid, and does work to render characters in Plane 1 blocks in desktop applications), PNG images
showing PHP and libgd's behaviour before and after the patch, and a mockup rendering showing
roughly what this is actually meant to look like, which you can get from:
http://www.adamharvey.name/stuff/bug51135.tar.bz2
Note that the attached patch isn't actually the whole solution, as is clear if you compare
with-patch.png to the mockup. It does make gdTcl_UtfToUniChar() decode the entities, but there are
evidently other issues that prevent non-BMP characters from actually being rendered properly, as
libgd bug 42 notes.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=51135
--
Edit this bug report at https://bugs.php.net/bug.php?id=51135&edit=1