Fixes#1808
When resolving a codepoint, we first attempt to find the default
presentation (if an explicit one is not given), but we were not falling
back to "any" in case that presentation was not found.
Related to #1768 but doesn't fix it properly.
This is a temporary hack to avoid some issues with fonts that have mixed
color/non-color glyphs. If there are mixed presentations and the font
does not have emoji codepoints, then we assume it is text. This fixes
the typical scenarios.
This is not a long term solution. A proper long term solution is to
detect this scenario and on a per-glyph basis handle colorization (or
the lack thereof) correctly. It looks like to do this we'll have to
parse some font tables which is considerably more work so I wanted to do
this first.
Fixes#1795
This only affected CoreText. When testing with Freetype the
strikethroughs looked correct for fonts with and without leading
metrics.
This commit adjusts our strikethrough position for fonts that have a
leading metric set to better center it. Previously, we centered the
position _including_ the leading value. The leading value is blank, so
we must center it excluding that value.
See: https://github.com/ziglang/zig/issues/17851
Users were noticing that frame render times got slower over time. I
believe (thanks to community for pointing it out) that this is the
culprit.
This works around this issue by clearing and reinitializing the LRU
after a certain number of evictions. When the Zig issue has a better
resolution (either rehash() as a workaround or a better hash
implementation overall) we can change this.
Allows for high dpi displays to get odd numbered pixel sizes, for
example, 13.5pt @ 2px/pt for 27px font. This implementation performs
all the sizing calculations with f32, rounding to the nearest pixel
size when it comes to rendering. In the future this can be enhanced
by adding fractional scaling to support fractional pixel sizes.
Now that we're padding the cells with blanks if we have shaped ligatures
we don't actually know the exact count based on the CoreText APIs, so we
should just dynamically add.
We previously split text runs for shaping on bg color changes. As
pointed out in Discord, this is not necessary, since we can always color
cells according to their desired background even if the text in the cell
shapes to something else.
Fixes#1708
Harfbuzz does this automatically. Our tests for harfbuzz test this. We
had a todo in CoreText to mimic this but wasn't sure if it was useful.
Turns out, it is important (see bug!)
