This commit introduces the `Dimension` type which allows specifying
a value in a variety of units; pixels, points, cells, percent.
`Dimension` needs contextual information to be evaluated as pixel
values, which makes resolving the value from the config slightly
more of a chore.
However, this type allows more flexible configurations that scale
with the font size and display dpi.
refs: #1124, #291, #195
More of a "fix"; we use some heuristics based on the bearing
and glyph width to figure out if a sequence looks like a funky
ligature that moves left to render the glyph.
This may be prone to false positives, but the consequences are low:
when we think a glyph is part of a ligature, then rather than using
the cursor_fg color (which is typically black, or close to invisible),
we retain the normal text fg color.
This way the portion of the glyph outside of the cursor retains its
foreground color, and just the cell containing the cursor may have
a slightly funky fg color in the case where the heuristic was bad.
closes: #478
We now compute the cap-height from the rasterized glyph data.
Moved the scaling action of use_cap_height_to_scale_fallback_fonts from
glyphcache into the font resolver: when enabled, and we have data
about the baseline font and the font being resolved, then the resolving
font will be scaled such that the cap-height of both fonts has the same
pixel size.
The effect of this is that `I` glyphs from both fonts should appear to
have the same height.
Added a row of `I`'s in differing styles at the bottom of styles.txt
to make this easier to visualize.
refs: #1189
This is to handle situations such as some versions of the Terminus
bitmap font, where the individual bitmap strike sizes are broken
out across multiple individual files.
Font matching now passes down the nominal pixel height based on
the current DPI and font scale factor, and will use that to select
the font file that has the closest pixel size.
Previously, it would be potentially undefined which of the Terminus
font files would be selected.
refs: https://github.com/wez/wezterm/issues/1189
This font is a bit funky; the bitmap strikes are only 4px wide:
```
; ftdump gohufont.otb
There is 1 face in this file.
----- Face number: 0 -----
font name entries
family: Gohu GohuFont
style: Regular
postscript: UNAVAILABLE
created: 1904-01-01
modified: 1904-01-01
revision: 1.00
glyph count: 1694
font type entries
FreeType driver: truetype
sfnt wrapped: yes
type: fixed size
direction: horizontal
fixed width: no
glyph names: no
fixed size
0: height 11, width 3
size 11.000, x_ppem 11.000, y_ppem 11.000
1: height 14, width 4
size 14.000, x_ppem 14.000, y_ppem 14.000
charmaps (1)
0: format 4, platform 3, encoding 1 language 0 (active)
```
but using that the cell size isn't right.
We draw from the metrics we compute via cell_metrics to get more
information; we don't get a valid height from that (just 0!), but
we do get the much more plausible width of 8 pixels.
So we take the max of the two techniques for figuring the metrics.
That appears to work out, and also doesn't appear to break emoji
fonts.
refs: #1165
This commit adjusts the the window event routing/queuing so that
a queued event can capture a pane_id other than the focused pane.
Since we only allow one queued instance of a given named event in a
window, a consequence of this is that multiple bell events coming
from different panes at the same time may race and the loser's
event will be dropped. We log a warning in that case.
refs: #3
This was a bit of a PITA to run down; the essence of the problem
was that the shaper was returning an x_advance of 0 for U+3000,
which caused wezterm's shaping layer to elide that glyph.
I eventually tracked down the x_advance to be the result of
scaling by an x_scale of 0, which in turn is the result of
harfbuzz not knowing the font size.
The critical portion of this diff is the line that advises
harfbuzz that the font has changed after we've applied the
font size.
The rest is just stuff to make it easier to debug and verify.
This:
```
printf "x\u3000x."
```
Now correctly renders on screen as "x x".
fixes: #1161
This commit introduces a mechanism for specifying resize increments
for a window, and then arranges for the termwindow to set those
to match the current font cell metrics.
This should help to avoid cases where there is excess padding pixels
resulting from the window being slightly larger than computed number
of cells and the font metrics.
It appears as though kakoune hides the terminal cursor and renders
its own version of the cursor.
The hidden state was being picked up by the copymode overlay,
making it awkward to use.
This commit forces the cursor to be visible (and a block) when
copy mode is active.
closes: #1113
Not sure what happened here: presumably a borked merge or something
similar, but this commit allows `window:get_appearance` to return
the actual appearance value on X11.
Even though this plumbs the call through to Wayland, Wayland doesn't
provide an equivalent concept so still always return Light, as is
mentioned on our docs.
closes: #1098
