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.
Unify grid metrics calculations by relying on shared logic mostly based
on values directly from the font tables, this deduplicates a lot of code
and gives us more control over how we interpret various metrics.
Also separate metrics for underlined, strikethrough, and overline
thickness and position, and box drawing thickness, so that they can
individually be adjusted as the user desires.
This commit makes CoreText behave a lot like FreeType where we set the
variation axes on the deferred face load. This fixes a bug where the
`slnt` variation axis could not be set with CoreText with the Monaspace
Argon Variable font.
This was a bug found in Discord. Specifically, with the Monaspace Argon
Variable font, the `slnt` variation axis could not be set with CoreText.
I'm not sure _exactly_ what causes this but I suspect it has to do with
the `slnt` axis being a negative value. I'm not sure if this is a bug
with CoreText or not.
What was happening was that with CoreText, we set the variation axes
during discovery and expect them to be preserved in the resulting
discovered faces. That seems to be true with the `wght` axis but not the
`slnt` axis for whatever reason.
Fixes#2364
This adds the bold, italic, and bold italic variants of JB Mono so it is
built-in. This also fixes up the naming convention for the embedded font
files across tests and removes redundant embedded font files.
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.
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.
Fixes#895
Every loaded font face calculates metrics for itself. One of the
important metrics is the baseline to "sit" the glyph on top of. Prior to
this commit, each rasterized glyph would sit on its own calculated
baseline. However, this leads to off-center rendering when the font
being rasterized isn't the font that defines the terminal grid.
This commit passes in the font metrics for the font defining the
terminal grid to all font rasterization requests. This can then be used
by non-primary fonts to sit the glyph according to the primary grid.
This maybe is a robust way to get Monaspace fonts working.
Previously, we used leading as part of the calculation in cell height. I
don't remember why. It appears most popular monospace fonts (Fira Code,
Berkeley Mono, JetBrains Mono, Monaco are the few I tested) have a value
of 0 for leading, so this has no effect. But some fonts like Monaspace
have a non-zero (positive) value, resulting in overly large cell
heights.
The issue is that we simply add leading to the height, without modifying
ascent. Normally this is what you want (normal typesetting) but for
terminals, we're trying to set text centered vertically in equally
spaced grid cells. For this, we want to split the leading between the
top and bottom.
* font: disable default font features for Menlo and Monaco
Both of these fonts have a default ligature on "fi" which makes terminal
rendering super ugly. The easiest thing to do is special-case these
fonts and disable ligatures. It appears other terminals do the same
thing.
