Bug #51135 [Asn->Sus]: imagettftext does not work for characters > 99999

From: Date: Mon, 22 Aug 2016 14:32:10 +0000
Subject: Bug #51135 [Asn->Sus]: imagettftext does not work for characters > 99999
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-203490@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=51135&edit=1 ID: 51135 Updated by: cmb@php.net Reported by: sharon_correll at sil dot org Summary: imagettftext does not work for characters > 99999 -Status: Assigned +Status: Suspended Type: Bug Package: GD related Operating System: Windows Vista PHP Version: 5.2.12 -Assigned To: tabe +Assigned To: cmb Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [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 "&#65537;" (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. ------------------------------------------------------------------------ [2010-03-05 15:55:25] pajoye@php.net aharvey@php.net: Not if the bundled is used. Which is the case on windows. Tabe, can you verify this issue please? ------------------------------------------------------------------------ [2010-03-05 15:45:14] sharon_correll at sil dot org Thank you for the information; it's helpful to know the status. ------------------------------------------------------------------------ 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

« previous php.bugs (#203490) next »