Variable font init used to just select the first available predefined
instance, if there were any, which is often not desirable- using
createFontDescriptorFromData instead of createFontDescritorsFromData
ensures that the default variation config is selected. In the future we
should probably allow selection of predefined instances, but for now
this is the correct behavior.
I found this bug when adding the metrics calculation test case for
CoreText, hence why fixing it is part of the same commit.
Fixes#2499
We rely on CoreText's font discovery to find the best font for a
fallback by using the character set attribute. It appears that for some
codepoints, the character set attribute is not enough to find a font
that supports the codepoint.
In this case, we use CTFontCreateForString to find the font that
CoreText would use. The one subtlety here is we need to ignore the
last resort font, which just has replacement glyphs for all codepoints.
We already had a function to do this for CJK characters (#1637)
thankfully so we can just reuse that!
This also fixes a bug where CTFontCreateForString range param expects
the range length to be utf16 code units, not utf32.
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.
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.
This gets `zig build -Dtarget=aarch64-ios` working. By "working" I mean
it produces an object file without compiler errors. However, the object
file certainly isn't useful since it uses a number of features that will
not work in the iOS sandbox.
This is just an experiment more than anything to see how hard it would be to
get libghostty working within iOS to render a terminal. Note iOS doesn't
support ptys so this wouldn't be a true on-device terminal. The
challenge right now is to just get a terminal rendering (not usable).
Fixes#707
Our scoring algorithm previously did not take into account symbolic
traits, so when `bold = false and italic = false`, regular, bold, italic
would all be equally likely to appear first.
This modifies our scoring algorithm to prioritize matching symbolic
traits. Further, we have a special case for no symbolic traits to
prioritize "Regular" named styles. We can expand this to other styles
too but we do not do this here.
We also modified the algorithm to always prefer fonts with more glyphs
over fonts with less, hopeful that we can load fewer fonts for other
glyphs later.
Fixes#668
We were previously only checking the first font result in the search.
This also fixes our CoreText scoring algorithm to prioritize faces that
have the codepoint we're searching for.
