You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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().
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 variableGDFONTPATH
. As is, we pass the$font_file
argument ofimagettftext()
and friends directly togdImageStringFT()
, 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 (seegdImageStringFTEx()
) (bundled libgd doesn't even support that).The text was updated successfully, but these errors were encountered: