Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement font lookup in ext/gd #17852

Open
cmb69 opened this issue Feb 18, 2025 · 2 comments
Open

Implement font lookup in ext/gd #17852

cmb69 opened this issue Feb 18, 2025 · 2 comments

Comments

@cmb69
Copy link
Member

cmb69 commented Feb 18, 2025

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).

@NattyNarwhal
Copy link
Member

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
Copy link
Member Author

cmb69 commented Feb 18, 2025

Wouldn't using fontconfig handle this?

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().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants