This allows us to upgrade freetype beyond 2.9.1 (actually, 2.8.1 due to a bug in freetype 2.9) without wildly different font metrics. The reason that we don't want to change font metrics algorithms is that freetype's new algorithm is very different than the algorithm used for SWF fonts. The older freetype algorithm is closer to SWF, so we want to stick with it.
Thankfully, freetype supports accessing various metrics stored in font files in a more raw form, so we can provide our own custom algorithm in a way that is fully supported by freetype. I just copied the existing algorithm straight from 2.9.1 to restore our preferred behavior.
I confirmed that, after this change, OpenFL renders metrics like Lime 8.1.3. But we have the same upgraded freetype as Lime 8.2.0 that we had to revert for 8.2.1.
I plan to experiment with a mode that matches SWF even more closely, now that I have a better understanding of how fonts and freetype work.
We use a default of 72 for now to ensure text is formatted correctly. Not entirely sure why we are stuck on 72 but that is an investigation for the future.
This fixes some unexpected changes in text rendering for OpenFL which rely on a private function in Lime. Previously we defaulted at 72 dpi, which apparently is expected to layout the text properly. Most displays are 96 dpi or higher today, so we should probably look into this. For RenderGlyph, which was previously broken over several versions, we will now use a dpi of 96 for now. In the next version of lime, we absolutely should alter the function signature to allow for renderGlyph to accept a dpi argument.
tag VER-2-9-1
Starting with freetype 2.10.0, the sum of the ascent and descent values seem to be more likely to be less than the baseline-to-baseline measurement (called the font's height), which is the font designer's recommend distance between baselines. However, OpenFL doesn't account for the full baseline-to-baseline height at all, so with smaller ascent and descent values, lines render with smaller gaps between them. OpenFL needs to update its TextEngine algorithm to use the height of the line instead of adding ascent and descent together alone, and then we can update freetype. Updating TextEngine is not a trivial change, and may likely require time to discover bugs and stabilize, so it's better to roll back the freetype update for now, and apply it again later after OpenFL can handle it properly.
I think it should probably use 96 dpi instead of 72.... In the next minor version of Lime I think we should change the function sig to allow a dpi argument.
We change the way RenderGlyph populates the binary data here. It's a little heavier than the 8-bit method used previously but I was having issues getting that to work properly with `Image`.
This change eliminates the cleanup attempt of the current OpenAL context and associated system resources. A change in OpenAL 1.20.0 made it unlikely that we will be able to clean up things in this way moving forward. We should steer users toward using `lime.system.System.exit()` or petition a change in the haxe stdlib to allow us to hook into Sys.exit().
I am not 100% satisfied with this, so perhaps we will find another solution. In the end, I think the benefit of updating OpenAL supersedes any inconvenience here.
Closes https://github.com/openfl/lime/issues/1803
Needed for macOS when using Xcode 16 and clang 16. This version of clang produces errors like this when compiling harfbuzz:
cast from 'void (*)(FT_Face)' (aka 'void (*)(FT_FaceRec_ *)') to 'FT_Generic_Finalizer' (aka 'void (*)(void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
This is the minimum version of harfbuzz that fixes the errors. We could certainly consider upgrading further (current release is 10.0.1 at the time of this commit).
Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
This is where arm64 homebrew installs `libneko.dylib`. However, it may still be in `/usr/local/lib` if installed via the haxe .pkg installer, so we add both.
On ios, we build statically linked executables. This means that if lime uses mbedtls 3, hxcpp is also forced to use it which can cause crashes and other problems, as hxcpp is currently written for 2.28
Casting `const char*` → `char*` is bad form, and we'd rather copy the string than do that. However, `GetGlyphIndex()` now takes a const, so neither workaround is needed.
