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.
Accounts for some changes to the native code called through cffi. We use 32 bit space (24 bit color) to create our image. We had some problems using 8 bit color previously. This might be a breaking change to anyone expecting an 8 bit image buffer, but it wasn't working for several versions anyway and this api is not used for anything within lime to render text as is.
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`.
Includes explanation that Sys.exit() bypasses Lime's ability to shut down its C++ subsystems, so System.exit() is recommended as best practice instead of Sys.exit().
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
Does not seem to recover when it happens, requiring the Lime app to be force closed. Some kind of threading issue that is affecting HashLink on Windows only (macOS and Linux are fine, and other sys targets are fine).
Fixed by passing SINGLE_THREADED to ThreadPool constructor using #if (windows && hl)
Example:
<config:air tsa="http://timestamp.digicert.com"/>
Required to workaround "Could not generate timestamp: Connection reset" error from adt with default timestamp URL.
We're currently using a version of hxcpp from GitHub instead of from Haxelib for macOS ARM64 support. Let's just use that version for all jobs, for consistency. Whenever hxcpp finally gets update on Haxelib, we'll switch to that version.
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).
These were added for drop-in compatibility with `BackgroundWorker`, but we might not need that level of compatibility. We can discuss adding these back later if there's demand.
