Since we may have two different sizes/namespaces of fonts between
the title font and the main terminal font, we need to be a bit more
careful to pass down distinguishing font information when caching
glyphs.
In addition, I noticed that the advance for custom block glyphs
(eg: powerline!) weren't right in the tab bar. To resolve this,
when shaping, we skip using the glyph from the font and synthesize
a placeholder with the appropriate advance.
Was mistakenly trying to use the windows font because of negative logic.
Tidy up, and prefer the gnome default theme font (Cantarell), but fall
back to DejaVu Sans.
We were truncating the right-status text because we were passing
the padded number of cols for the tab bar, but since the tab bar
now exists outside the padding, that value was too small.
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
The previous commit was partially OK, but the main cause of
emoji being wonky was this bit of macos specific code that I
added ages ago.
Remove that hack and the portion of the code from the previous
commit that was working to undo it.
This should make the baselines consistent across all platforms.
refs: #1203
Avoid accidentally scaling the tab bar when using IncreaseFontSize.
Use a "better" default title font based on the platform.
Avoid a gap between bottom of tab button and dividing line at
certain font sizes.
When split horizontally, selecting multiple lines at the top of the left
pane could paint a horizontal selection line all the way across the rest
of the terminal to the right hand edge.
Removes the dependency on knowing where the pane top/left position
is so that the line render routine could be used in more places.
Adjusts the tab bar and scroll bar positioning so that the tab bar
ignores window padding and is always flush with the top/bottom window
edge (full width as well), and that the scroll bar top/bottom respects
the tab bar position and height.
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
`use_fancy_tab_bar` switches to an alternate rendering of the tab
bar that uses the window_frame config to get a proportional
title font to use to render tabs, as well as rendering a few
additional elements to space out and make the tabs feel more
like tabs.
Computing the number of tabs doesn't respect the alternate font
at this time.
Formatted tab item foreground and background colors are also
not respected at this time.
refs: #1180
The description of Nop was incorrect; it was describing
DisableDefaultAssignment. Just make this bit use the same
example from DisableDefaultAssignment's docs.
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
