More recent versions of harfbuzz conveniently generate harfbuzz.cc
which has the full list of source files, so point our build to
that instead of chasing the evolving list of files: much easier!
Fixup some of the predefined symbols, and include opentype functions
in bindings.h so that we can pick those up in the bindgen output.
Freetype has a compile-time feature that, when enabled, rewrites the
font names of PCF fonts to include the foundry and wide status of the
font in order to disambiguate the various versions of fonts all named
"Fixed".
That option is enabled by default in some linux distributions but not
all; it's not enabled in Fedora, for example.
When that feature is enabled it causes problems for the Terminus font as
the PCF version of the fonts are no longer resolvable via the simple
"Terminus" name but via "xos4 Terminus" instead.
wezterm builds its own version of freetype (for consistency and cross
platform support reasons), and is unaware of the choice used by the
distro.
The result of that is that fontconfig may see PCF fonts as having
different font names than how wezterm sees them.
A concrete problem is on such a system, when requesting "xos4 Terminus",
fontconfig will present a match with that name, but when wezterm opens
the font and sees that it has name "Terminus" (because of the difference
in this feature in the freetype libraries in use), wezterm will reject
that match.
This commit enables that option in the freetype library and adds a
wezterm config level option (freetype_pcf_long_family_names) that can be
used to control the underlying pcf font driver configuration.
The upshot of this is that this commit doesn't change any default
behavior, but allows users of those systems to set
`freetype_pcf_long_family_names = true` to turn that behavior on.
My personal opinion on this is that users probably shouldn't use this if
they can avoid it (and PCF fonts in general), and instead install the
OTB version of the Terminus font, which doesn't have this legacy baggage
associated with it!
refs: https://github.com/wez/wezterm/issues/2100
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
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
By default, freetype doesn't include error strings and FT_Error_String
will always return NULL. Turn on the compile time option that makes
this function useful!
Weird that this was set to not enable C++, but I suspect it is the
reason why the C++11 compiler flag isn't being added to resolve this:
```
warning: harfbuzz/src/hb-meta.hh:41:18: warning: variadic templates are a C++11 extension [-Wc++11-extensions]
warning: template<typename... Ts> struct _hb_void_t { typedef void type; };
```
This commit more cleanly separates the load from the render flags,
and fixes up the render call; at some point this got messed up such
that we'd never end up with freetype returning subpixel format data
(LCD) and instead we'd only ever get grayscale data.
With that fixed, it's apparent that the colorization of the glyph
data was wonky in the shader so this commit also cleans this up.
refs: #320
refs: #121
`cargo test --release --all` was broken by a recent update.
Interesting that it only broke when building tests.
Regardless: these deps should probably have always been required,
so this is a legit change.
Forgetting to update the submodules is a commonly reported build
issue with an obscure error message:
```
CMake Error: The source directory "/home/USER/wezterm/target/debug/build/freetype-430fe24cb64c561c/out/zlib-src/zlib" does not appear to contain CMakeLists.txt.
```
this teaches the build.rs machinery to run the submodule update
if it looks like it is needed.
