RE: imagettftext with UTF-8 and long paths in PHP 7.1

Hi Christoph,

Thanks for the investigations.

> -----Original Message-----
> From: Christoph Becker [mailto:[email protected]]
> Sent: Saturday, July 16, 2016 2:44 AM
> To: [email protected]
> Cc: Anatoliy Belsky <[email protected]>
> Subject: imagettftext with UTF-8 and long paths in PHP 7.1
> 
> Hi!
> 
> While running the ext/gd tests on Windows I've stumbled upon bug48732-
> mb.phpt[1].  The test is marked as XFAIL "seems freetype issue, to investigate".
> I've tried to solve the issue, but I'm stuck.
> 
> The first issue is that libgd uses the macro access() to check whether the given
> filename can be accessed[2].  In the bundled libgd, access is defined as
> _access[3], what obviously can't work.  As quick workaround, I changed that to
> tsrm_win32_access, and that lets the check succeed.
> Of course, it's not possible for libgd to depend on a PHP API, so that would
> require another solution.  Anyhow, the system libgd[4] includes <unistd.h> and
> uses access (what presumably maps to _waccess).  (I'm deliberately ignoring the
> Windows Mobile/CE fallback library, at least for now).  If we'd use _waccess
> also for the bundled libgd (which might happen anyway, as synchronizing the
> bundled and the system libgd is work in progress), it *might* be possible to do
> the conversion in the PHP binding and pass the UTF-16 filename to
> gdImageStringFT().  I don't know if there is a simple way to convert from
> default_charset to UTF-16, though.
> 
For conversions to UTF-16, please check the win32/codepage.h and win32/ioutil.h APIs. Were it possible to pass UTF-16, it could be done easy. The standalone libgd wouldn't probably know about the source encoding for conversion. So either it'd need to accept UTF-8 and use wide APIs, or provide callbacks for IO functions, etc. 

> The next issue is that FT_New_Face()[5] is called to retrieve a face.
> However, freetype seems to use fopen(), which also won't work.  On
> StackOverflow[6] I found the suggestion to load the file into memory, and then
> to use FT_New_Memory_Face().  That appears to be a viable solution, but I
> wouldn't know how to implement it.
> 
Yeah, same here. If a file is read into the buffer, FT_New_Memory_Face() should be fine. If we could pass the buffer to libgd, so it'd be solved without having to touch freetype. But since this is done internally in libgd, the only way is to have a proper solution in there.

> Anyway, I consider supporting arbitrary default_charset for font filenames to be
> rather low priority (at least ASCII names should work fine, mostly), but perhaps
> someone may want to solve this issue, and hopefully my findings would be
> helpful in this case.
> 
That was also my motivation to put an XFAIL in some tests. While one could potentially patch some dependency, send a patch upstream and make it ready for use with PHP, it's not always the right way. Passing ctx as mentioned by Pierre, already solves the general case. With most of our dep libs UTF-8 path is not of an issue, either they support it or PHP streams can be used which now support it as well. The worst case is that only ANSI and _MAX_PATH long path is supported, which is the limit prior to the UTF-8 patch.

Regards

Anatol