As mentioned in f204ad9a82, this has
gone back and forth a few times.
This version avoids some artifacts by avoiding scaling in most cases.
The test scenario for this is to tab complete a directory name in
zsh; that causes a bold `/` glyph to be rendered which selects a
typeface with different metrics and would render a horizontal line
at either the top of bottom of the glyph.
Similarly, a `/` in italics (eg: comments in vim) would select a
third different font and have different artifact properties.
Now both of those artifacts are eliminated.
The issue mentioned from the prior commit was due to not breaking
out of the inner fallback loop, so we'd stack up multiple glyphs
with the same cluster value, causing the earlier versions to be
obscured by the later versions.
Adjust glyph width calculation: the metrics we were getting from
harfbuzz were synchronized with the font render size. When we're
configured to use allsorts, the shaper metrics are not connected
to the render metrics and we can end up with the raw emoji glyph
width being much larger than the font advance metric value and
then render a giant heart emoji. The revised calculations trigger
scaling if the glyph width is too wide. I've gone back and forth
on that particular line a couple of times in the past: hopefully
this time we've got the right calculation?
I "fixed" the font metrics we compute and return from allsorts
by rounding them to the nearest integer value. That makes the
spacing look better at my normal font size (8.3 -> 8) and makes
things look tighter. It feels a bit magical IMO.
Adds the ability to specify `--font-shaper Allsorts` and use that
for metrics and shaping.
It is sufficient to expand things like ligatures, but there's something
slightly off about how the metrics are computed and they differ slightly
from the freetype renderer, which leads to some artifacts when rendering
with opengl.
One of my tests is to `grep message src/main.rs` to pull out the line
that has a selection of emoji. The heart emoji is missing from that
line currently.
Refs: https://github.com/wez/wezterm/issues/66
This commit makes use of the allsorts font parser to
parse out matching fonts found under the `font_dirs`
locations.
The matching is imperfect but sufficient for my ad-hoc
local tests.
Using allsorts for this parsing/matching means that we
can implement font_dirs on all platforms; previously it
was only available when using some plumbing from font-kit.
Refs: https://github.com/wez/wezterm/issues/74
I don't think font-kit has enough data available for to make things
work the way we're used to. In addition, the implementation of
the loader for core text has a lot of TODO's.
The state of the FontKit variant is that it basically renders glyphs
and they are aligned to the same baseline, but both the vert and
horz metrics are off; for example, `-` doesn't render. The glyphs
are also under-sized.
This is another option to help with the portable wezterm on a flash
drive use case.
When the font system is set to FontKitAndFreeType, the set of
directories specified by the `font_dirs` configuration option will
be scanned for fonts and used as a source for fonts.
In addition, any relative paths in the the `font_dirs` list will
be expanded relative to the configuration file path.
That allows deploying the following set of files to the root of
a flash drive:
* wezterm.exe
* wezterm.toml
* fonts/myfont.ttf
and with this config snippet:
```
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
```
wezterm will now consider myfont.ttf when loading fonts.
Refs: https://github.com/wez/wezterm/issues/73
