This commit allows the x11 window implementation to detect changes
in the DPI that occur after a window is created.
These can occur when changing desktop resolution or when changing
the accessibility option for "Large Text" in gnome.
In order to avoid continually polling for the value on every resize,
we look for the `_GTK_EDGE_CONSTRAINTS` atom in our property change
notifications. This seems to be sent at least as often as the
dpi/scaling changes.
It's also worth noting that some dpi changes don't generate resize
events, so we can't just read the dpi value on every resize, because
we'd miss some of those changes.
Part of this commit changes the font scaling logic: previously
we'd keep a notion of "dpi scale" to apply. That dates from an
earlier time in wezterm where we didn't think that we knew an
actual dpi value.
The way that worked was that we'd compare our current guestimate
of the DPI against what we though the baseline OS dpi should be to
produce a scaling factor.
On X11 that dpi value is global and we'd effectively always produce
a revised scaling factor of 1 after we'd set up the initial window.
This commit changes that logic to just pass down the actual DPI value
to the font code. That DPI value already accounts for HiDPI scaling
so this is hopefully a NOP change for the other systems.
refs: https://github.com/wez/wezterm/issues/667
Replaces the last usage of ttf-parser with calling into freetype.
This removes a source of inconsistency, as ttf-parser doesn't support
all of the things that freetype does.
Notably, this prevents a weird error from blowing up codepoint coverage
calculations on a system where I have helvetica.bdf in my font dir for
long-forgotten reasons.
```
WEZTERM_LOG=wezterm_font=trace,info wezterm
```
will list fonts found in font_dirs and the builtin fonts.
It can't show all fonts found via the system locator, because
that only has an interface for finding fonts by matching name,
not listing all of them.
With this configuration:
```lua
local wezterm = require 'wezterm'
return {
font_dirs = {"/Users/wez/Downloads/Inconsolata"},
font = wezterm.font("Inconsolata"),
font_locator = "ConfigDirsOnly"
}
```
wezterm is now able to see the 74 variations that are available
in the single inconsolata ttf.
Running `WEZTERM_LOG=wezterm_font=trace wezterm` will log the
variations.
refs: https://github.com/wez/wezterm/issues/655
If shaping can't resolve some glyphs, queue the font locator
fallback resolution to another thread; meanwhile, a last resort
glyph is used.
That thread can trigger an invalidation once the fallback resolve
is complete, the window is invalidated and the last resort glyph
is replaced by the resolve glyph.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/508
Keep track of the glyphs we've already advised about (until the
config is reloaded) so that we don't keep spamming the user.
refs: https://github.com/wez/wezterm/issues/559
* Check built-in fonts before asking the system for codepoint coverage
* If one of the earlier stages resolved some fonts, skip the remaining
stages and speculatively shape what we have. This avoids triggering
the system font lookup for fonts that are present in the font_dirs
or that are built-in, such as powerline symbols.
refs: https://github.com/wez/wezterm/issues/559
The dwrote crate offers functions that can extract the underlying
font file name(s) from the system, so let's use those to get
OnDisk font handles and save some memory.
refs: https://github.com/wez/wezterm/issues/559
In an earlier incarnation of both wezterm and freetype, FT_New_Face
would lead file descriptors into child processes because it didn't
set O_CLOEXEC. That led to the slightly pessimistic approach of
loading the font into memory for the lifetime of the wezterm process.
With the improved fallback handling on macos, this can result in
hundreds of MB of font data being loaded, in some cases multiple
times.
Since those days, freetype now sets O_CLOEXEC and wezterm has some
logic to close other random fds, so the descriptor leaking problem
is gone and we can now let freetype manage a file handle instead
of a memory-baked font.
This reduces the memory utilization by at least 1GB in the case
that a glyphs need to be resolved from the system fallback fonts.
refs: https://github.com/wez/wezterm/issues/559
terminus-bold.otb reports 0 height!
Detect and force that case to go through the bitmap strike loading
code path.
Improve the size selection heuristic for bitmap strikes: previously,
we would just pick the largest bitmap and allow it to be scaled down,
which was OK for emoji fonts that just had 128px square glyphs, but
is not ok for pre-rendered pixel strikes like terminus.
Note that IncreaseFontSize works in terms of percentages only,
so using a font like this may have "gaps" when ctrl-+ or - to change
the font size.
refs: https://github.com/wez/wezterm/issues/560
This is a bit unfortunate, but necessary, because the system fallback
list contains a handful of special fonts that apple doesn't ship on
disk in ttf/otf files.
One of those is `.AppleSymbolsFB` which would normally satisfy
the symbol lookup.
This commit hard codes the "Apple Symbols" font to use instead,
which is a disk based font. I don't know what the difference
is between it and `.AppleSymbolsFB`, but this is sufficient
to satisfy the glyph in question from the referenced issue.
refs: https://github.com/wez/wezterm/issues/506
