This adds to the heuristics introduced for #1071. Please read that issue
and associated PRs in their entirety to understand this commit.
This extends our concept of "whitespace" to include powerline box
glyphs. We don't want to constrain nerd symbols next to powerline box
glyphs because box glyphs are often used to style and contain nerd
glyphs. For example, its common to see a right-facing semi-circle, then
a nerd font glyph, then a left-facing semi-circle to create a
pill-shaped label.
This allows those nerd font symbols to be rendered full size. Test
script below (copy the bytes):
printf "\n"
printf " \n"
printf "\n"
Dingbats are generally symbolic glyphs that frequently overflow the
cell. Their defined codepoint width is "1" so they take one cell but
very often overflow to the next.
This extends the previously created logic for Nerd Font symbols such
that when a dingbat is next to whitespace, we allow it to use the full
size, but when a dingbat is next to an occupied cell we constrain it to
the cell size.
Up to this point, every font I've experienced with ligatures has
replaced the codepoints that were replaced for combining with a space.
For example, if a font has a ligature for "!=" to turn it into a glyph,
it'd shape to `[not equal glyph, space]`, so it'd still take up two
cells, allowing us to style both.
Monaspace, however, does not do this. It turns "!=" into `[not equal
glyph]` so styles like backgrounds, underlines, etc. were not extending.
This commit detects multi-cell glyphs and inserts synthetic blank cells
so that styling returns. I decided to do this via synthetic blank cells
instead of introducing a `cell_width` to the shaper result because this
simplifies the renderers to assume each shaper cell is one cell. We can
change this later if we need to.
Annoyingly, this does make the shaper slightly slower for EVERYONE to
accomodate one known font that behaves this way. I haven't benchmarked
it but my belief is that the performance impact will be negligible
because to figure out cell width we're only accessing subsequent cells
so they're likely to be in the CPU cache and also 99% of cells are going
to be width 1.
Rather than immediately converting a color palette index into an RGB
value for a cell color, when a palette color is used track the palette
color directly in the cell state and convert to an RGB value in the
renderer.
This causes palette color changes to take effect immediately instead of
only for newly drawn cells.
This returns an error from the renderer implementation. This error just
crashes Ghostty currently with a stack trace. We can handle the error
later but for now it makes it a lot more obvious why certain error
scenarios happen.
This adds the Powerline glyphs to the exemptions from the PUA
constraints put in as a part of #1110.
While Powerline is considered to part of the Nerd Font group, the
constraint behavior seems to cause issues with some setups - e.g.
powerlevel10k prompts where characters immediately follow a Powerline
character.
Only the codes given as shapes below are included:
https://github.com/ryanoasis/powerline-extra-symbols/blob/master/img/fontforge.pngFixes#1113, where the issue can be seen.
Fixes#1101
GTK forces all GLArea drawing to happen on the GUI thread. In this
scenario, `updateFrame` and `drawFrame` could be happening in parallel.
This commit grabs the lock while updating the Kitty image protocol state
since that is used by both functions.
We already have a mutex called "draw_mutex" that we hold while we're
modifying data that could be shared by this separate draw thread. We
should reuse that here.
Fixes#1037
Renderers must convert the internal Kitty graphics state to a GPU
texture for rendering. For performance reasons, renderers cache the GPU
state by image ID. Unfortunately, this meant that if an image was
replaced with the same ID and was already cached, it would never be
updated on the GPU.
This PR adds the transmission time to the cache. If the transmission
time differs, we assume the image changed and replace the image.
Fixes#882
We previously had a hardcoded limit of 16 codepoints. In #882, a user
pointed out that in Chinese, is reasonable for a preedit input to be
longer than this.
To avoid any future issues, this commit moves to a heap-allocated
variant. Preedits aren't that common, they aren't high throughput, and
they're generally pretty small, so using a heap allocation is fine. The
memory is owned by the person who set it.
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.
