Repository navigation
Implement font lookup in ext/gd #17852
Description
Description
As is, libgd supports a somewhat complex font lookup for gdImageStringFT() (and friends). You can actually pass a semicolon delimeted list of fonts, and each font can be an absolute or relative path to a font file, or a suffix to any of the default font paths, which are hard-coded for different platforms, but which also can be overridden via the environment variable GDFONTPATH. As is, we pass the $font_file argument of imagettftext() and friends directly to gdImageStringFT(), so libgd does all the heavy work to actually find the desired font.
However, this does not (necessarily) work for ZTS builds when relative paths are given, since external libgd is not aware of the VCWD (while bundled libgd is) (see #17366). In addition, changing a global enviroment variable doesn't fit well to our ZTS model (see #16565 (comment)). And there are also some minor issues with the libgd implementation (e.g. libgd/libgd#952).
In my opinion, the font lookup in libgd should have better been split from the actual drawing functions, what would have allowed us to implement our own font lookup in the first place, properly catering to VCWD and what not (e.g. fontconfig support, which is implemented in libgd, but not supported from ext/gd). Now this is moot, but I still suggest to implement our own font lookup in ext/gd (basically re-implementing what libgd does), and then to pass only a single absolute font path to gdImageStringFT(). This would allow to compensate the current incompatibilites between external and bundled font lookup (partially paving the way to unbundle libgd), and would also allow us to make further improvements (especially fontconfig comes to mind), with having to deal with the somewhat messy way that is implemented in external libgd (see gdImageStringFTEx()) (bundled libgd doesn't even support that).
Activity
NattyNarwhal commentedon Feb 18, 2025
Wouldn't using fontconfig handle this? External libgd can use that, though our bundled one seems incapable of it. Though I'm not sure how useful fontconfig is on Windows; it might be useful for this on Unix.
cmb69 commentedon Feb 18, 2025
Well, I don't think we can force users to use a libgd with fontconfig support, nor require them to use a fontconfig pattern (let alone that this is not supported by ext/gd anyway). I consider it not uncommon that some software ships a font file, and the software might just want to use that. Passing a relative path to that file works fine under NTS, and also under ZTS when using the bundled libgd; with ZTS/external libgd, you can use
realpath().2colours commentedon Nov 27, 2025
That "minor issue" in the libgd implementation just broke my Discord bot for the mere fact that I was using a relative path to my bundled font, it took me quite some time to dig it out since I don't even directly use Gd, just Intervention/Image.
pierrejoye commentedon May 22, 2026
hello :)
Coming here from a ref in libgd's gh bug.
A few background and explanations may be needed.
I think adding FC to gd long ago was a magistral mistake. It is not gd's role to handle that but to render text using a given font path. Almost no other similar libraries provide FC support but let the callers handle it as desired and path a font path.
Fonts are a nightmare. Not only the formats but how they work and may allow. All OSes, FontConfig and similar tools have CVE DBs full of issues with fonts, from crashes in best case to RCE. For desktop applications or similar (phpnative and related f.e.), that sounds handy but the risks are still there. For web apps, an absolute no go.
I would rather have a separate fonts resolver extension using the right system's APIs on different OSes. Like Windows have more "secure" (add many double quotes there), MacOs too afair. But allowing font replacement from random files, with paths which can be overridden using envs is just a big no.
UNC path is very close to the above for fonts (or exec for what matters), not necessarly for public web apps, but local intranets f.e.
From a libgd perspective, I would only recommand to only use absolute paths and pass it. That allows openbase_dir when needed, and limit a bit the risks, but for those allowing users to upload their own fonts and then use them in the app. Another reason for this is explained here earlier, NTS vs TS. libgd (or any external libs) have no idea about app's CWD vs current CWD/process' CWD.
As of Netware, did we not drop Netware years ago in php? it is dropped in libgd as well. That should be removed in any case in that area :)
I may have time later next month to work on a merge libgd > php's libgd and do some cleanups, but I would do it for the next 8.x, except if an actual security issue happens in between.