At certain font sizes, this avoids clipping the text. This is due to a
limitation of the CoreText API, which does not provide a way to measure
the exact size of the text that will be rendered when antialiasing is
enabled.
Fixes#2081
Many fonts have a bad ligature for "fl", "fi", or "st". We previously
maintained a list of such fonts in quirks.zig. However, these are so
common that it was suggested we do something more systematic and this
commit is that.
This commit changes our text run splitting algorithm to always split on
`fl`, `fi`, and `st`. This will cause some more runs for well behaved
fonts but the combination of those characters is rare enough and our
caching algorithm is good enough that it should be minimal overhead.
This commit renders our existing quirks fonts obsolete but I kept that
logic around so we can add to it if/when we find other quirky font
behaviors.
Some CoreFoundation objects, such as those produced by CoreText, have
expensive callbacks that run when they are released. By offloading the
CFRelease calls to another thread, we can avoid important threads being
blocked by unexpectedly expensive callbacks.
This commit also changes the way that the coretext shaper's run iterator
builds its string. Rather than using a CFMutableString, an ArrayList of
unichars is built which is passed to CFStringCreateWithCharactersNoCopy,
which is a lot more efficient since it avoids all the CoreFoundation
overhead.
Fixes#1722
Previously, SharedGrid.getIndex would properly lock any access to search
for and load the face metadata for a font face that contains a
codepoint. However, that face may be "deferred" (metadata loaded but the
actual face not loaded).
Later, outside of the SharedGrid write lock, a deferred face may be
initialized and cause a data race if two threads are doing this at the
same time, sometimes loading to a crash.
This commit fixes the issue by always preloading font indexes in
getIndex because the usage of getIndex implies a very near term future
use of getFace.
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.
