I'm experimenting with using cairo's 2D graphics for glyph related
drawing operations, and perhaps more stuff in the UI in the future.
The challenge is that no one has yet encapsulated its build in a
cargo-friendly way.
This commit is that attempt.
The strategy is this:
* `deps/cairo` is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys
which is the cairo-sys-rs crate
* Its build.rs has been replaced with a version that builds from the C
sources that are found in-tree; it will never look for the system
cairo library
* A pair of scripts to import pixman (a required dep of cairo) and
cairo itself in a repeatable way are include, for if/when we need
to update the vendored sources
Cairo is a mature library and doesn't release very often.
* The workspace sets a patch for crates.io so that cairo-rs has
its cairo-sys-rs dep redirected to the local build.
I'm not planning to upstream this stuff to gtk-rs-core as full cairo
depends on a lot more things than are dealt with here, so it would be a
PITA to handle that generally.
This vendoring strips out things that are not used, so the cairo
library that remains:
* Is not internally thread safe; no TLS or mutex support is enabled
in either of them. That's fine because the high level cairo-rs
wrapper is not Send+Sync, which means that rust will only allow
it to be used single threaded anyway.
* Only has the basic recording and image surfaces
* No platform support for win32/xlib/xcb and so on
The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
```
warning: voidpf ZLIB_INTERNAL zcalloc (opaque, items, size)
warning: ^
warning: zlib/zutil.c:315:20: warning: a function declaration without a prototype is deprecated in all versions of C and is not supported in C2x [-Wdeprecated-non-prototype]
```
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
