This adds in-terminal rendering for the powerline glyphs E0B4 and E0B6,
similar to how we are rendering the triangle shapes currently.
The circle glyphs use a much more complex rendering due to the nuances
of drawing them: we use a midpoint algorithm for drawing on a 4x
supersampled matrix, fill, and then downsample. We use the same
downsampling approach as is done in the arc box drawing code.
The midpoint variant we're using here is described by Dennis Yurichev:
https://yurichev.com/news/20220322_circle/, although there are similar
variants elsewhere (some cited at the bottom of his article).
Fixes#991
This changes the default embedded font from Fira to JetBrains Mono. This
only affects users who don't specify or font AND Ghostty can't find
another default font to use on their system.
This is one part an aesthetic choice: I've grown to personally like
JetBrains Mono more than Fira, and I think I have the right to change
the defaults ;)
But this is also partly because of #991: FiraCode contains glyphs for
symbolic ranges. This may not be Fira official... I think I may have
used a Nerd font patched one and that may be the issue. So I don't want
to blame the Fira font project. BUT, we have to replace the ttf in our
project and since I've been meaning to switch to JB Mono I just did that
now.
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 adds the Powerline face to our set of built-in faces, which
represents glyphs that are used to draw Powerline-style shell prompts
and status lines.
Since these are used similar to box-drawing characters, alignment is
important, and this gives us the most control in preventing related
artifacts.
This initial commit is scaffolding and support for the various solid
triangles - additional glyphs will come in other commits.
Fixes#675.
Related to #914
U+200D is the zero-width joiner character used for multi-codepoint
Emojis. When faced with a multi-codepoint grapheme, the font shaper must
find a font that provides _all codepoints_ consistently. However, U+200D
isn't meant to be provided by any font. As a result, the font shaper
search ends up iterating over every font looking for a match.
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.
Fixes#845
Quick background: Emoji codepoints are either default text or default
graphical ("Emoji") presentation. An example of a default text emoji
is ❤. You have to add VS16 to this emoji to get: ❤️. Some font are
default graphical and require VS15 to force text.
A font face can only advertise text vs emoji presentation for the entire
font face. Some font faces (i.e. Cozette) include both text glyphs and
emoji glyphs, but since they can only advertise as one, advertise as
"text".
As a result, if a user types an emoji such as 👽, it will fallback to
another font to try to find a font that satisfies the "graphical"
presentation requirement. But Cozette supports 👽, its just advertised
as "text"!
Normally, this behavior is what you want. However, if a user explicitly
requests their font-family to be a font that contains a mix of test and
emoji, they _probably_ want those emoji to be used regardless of default
presentation. This is similar to a rich text editor (like TextEdit on
Mac): if you explicitly select "Cozette" as your font, the alien emoji
shows up using the text-based Cozette glyph.
This commit changes our presentation handling behavior to do the
following:
* If no explicit variation selector (VS15/VS16) is specified,
any matching codepoint in an explicitly loaded font (i.e. via
`font-family`) will be used.
* If an explicit variation selector is specified or our explicitly
loaded fonts don't contain the codepoint, fallback fonts will be
searched but require an exact match on presentation.
* If no fallback is found with an exact match, any font with any
presentation can match the codepoint.
This commit should generally not change the behavior of Emoji or VS15/16
handling for almost all users. The only users impacted by this commit
are specifically users who are using fonts with a mix of emoji and text.
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#757
The x/y is unsigned (as it should be, since top-left is 0,0). In the
case of a very small grid size and certain thickness settings, its
possible to overflow. In this scenario, the only reasonable thing to do
is just clamp to 0 because some sprites are going to look weird with
small enough grids anyways.
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.
