1
1
mirror of https://github.com/wez/wezterm.git synced 2024-12-27 07:18:13 +03:00
Commit Graph

54 Commits

Author SHA1 Message Date
Wez Furlong
af815a2e1b fonts: add freetype_pcf_long_family_names option
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
2022-06-09 20:09:47 -07:00
Wez Furlong
8f880551a0 deps: harfbuzz -> 4.3.0 2022-05-24 18:43:10 -07:00
Wez Furlong
9bf732bcae update harfbuzz to 4.2.1 2022-04-24 16:40:53 -07:00
Wez Furlong
e76525b695 deps: harfbuzz -> 4.2.0 2022-04-03 18:37:25 -07:00
Wez Furlong
8eb497fa19 deps: harfbuzz -> 4.1.0 2022-03-26 10:51:35 -07:00
Wez Furlong
d64f0c2189 deps: harfbuzz -> 4.0.1 2022-03-12 07:06:54 -07:00
Wez Furlong
a79fc87586 deps: harfbuzz -> 3.4.0 2022-02-12 16:00:58 -07:00
Wez Furlong
1b63b4b7c9 deps: harfbuzz -> 3.3.2 2022-02-06 06:44:59 -07:00
Wez Furlong
7d8819b8d6 freetype: regenerate ffi bindings 2022-01-31 20:39:05 -07:00
Wez Furlong
40eef5b5dd harfbuzz: regenerate ffi bindings 2022-01-31 20:35:12 -07:00
Wez Furlong
05354fe8e5 deps: update harfbuzz to 3.3.1 2022-01-31 20:32:20 -07:00
Wez Furlong
e4ed2c93e2 encoding my preferred import grouping in the rustfmt config
This uses an unstable option in rustfmt, you `cargo +nightly fmt`
needs to be used to format the code correctly.
2022-01-17 13:50:51 -07:00
Wez Furlong
baf879f4f8 upgrade freetype to 2.11.1
refs: #1419
2021-12-20 08:22:34 -07:00
Wez Furlong
88688e32c7 update harfbuzz to 3.2.0 2021-12-11 20:36:53 -07:00
Wez Furlong
b8bc9dc01b freetype: expose some more constants 2021-10-10 10:18:47 -07:00
Wez Furlong
2a4cbf0d59 freetype: expose sfnt name functions 2021-10-10 10:14:41 -07:00
Wez Furlong
401719fb01 fonts: improve cap-height and use_cap_height_to_scale_fallback_fonts
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
2021-10-02 18:23:51 -07:00
Wez Furlong
2c251acd25 free2type: update for Windows access violation
A stupid MSVC compiler behavior meant that an array wasn't
properly initialized.

This commit resolves it.

https://gitlab.freedesktop.org/freetype/freetype/-/issues/1075
2021-09-26 14:48:48 -07:00
Wez Furlong
f648d8a6a5 deps: Upgrade to freetype 2.11 2021-09-25 00:43:23 -07:00
Wez Furlong
b16f584866 deps: harfbuzz -> 3.0.0 2021-09-18 09:04:23 -07:00
Wez Furlong
c870c73dbe deps: update harfbuzz to 2.9.1 2021-09-09 09:01:42 -07:00
Wez Furlong
fc441e9879 Upgrade bundled harfbuzz library to 2.9.0 2021-08-23 21:59:16 -07:00
Wez Furlong
c37ee01222 fonts: synthesize bold when missing
refs: #815
2021-05-22 16:20:35 -07:00
Wez Furlong
43ea2f192a Allow matching font weight and font width in wezterm.font
refs: https://github.com/wez/wezterm/issues/655
2021-04-08 15:42:53 -07:00
Wez Furlong
80aa86fa0c fonts: parse weight and italic into ParsedFont 2021-04-07 20:00:41 -07:00
Wez Furlong
e200605b8f fonts: add support for "variable" fonts
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
2021-04-07 17:45:38 -07:00
Wez Furlong
2902a76c5c lint: fix some clippy stuff 2021-03-25 10:05:34 -07:00
Wez Furlong
32cb44c225 bump freetype dep to VER-2-10-4 2021-01-25 21:35:47 -08:00
Wez Furlong
ba9bc30b79 harfbuzz: skip some unused bits
don't bother building the coretext or uniscribe bits of harfbuzz
2020-12-05 14:19:47 -08:00
Wez Furlong
4fd574cc7f freetype: enable FT_Error_String
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!
2020-11-25 16:19:56 -08:00
Wez Furlong
3309803925 ci: speculative fix for C++11 build break in harfbuzz
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; };
```
2020-11-23 14:33:47 -08:00
Wez Furlong
dc453f2eed deps: update bundled harfbuzz to 2.7.2 2020-11-23 08:43:53 -08:00
Wez Furlong
9892b16d40 wezterm-font: tidy up some font hinting/aa options
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
2020-11-14 17:27:31 -08:00
Jeremy Fitzhardinge
7bfe83da6b libpng: build NEON support for ARM and Aarch64 targets 2020-11-11 20:31:18 -08:00
Wez Furlong
124fe559cd fixup win32 build
`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.
2020-08-29 10:03:07 -07:00
Wez Furlong
bd179fa56c try to target older macos releases
refs: https://github.com/wez/wezterm/issues/128
2020-01-27 00:12:47 -08:00
Wez Furlong
1bf0402844 fixup submodules 2019-11-24 13:41:32 -08:00
Wez Furlong
bc7363465e suppress C build warnings for font related deps 2019-11-05 21:04:37 -08:00
Wez Furlong
09e70357b3 don't link test executable entrypoint into libpng 2019-11-04 09:40:27 -08:00
Wez Furlong
ceba08cb59 fixup build on windows 2019-11-04 09:40:27 -08:00
Wez Furlong
a199ced513 build libz, libpng, freetype, harfbuzz without cmake
use the cc crate to compile them directly
2019-11-04 09:40:27 -08:00
Wez Furlong
61b27c8089 teach build.rs to init submodules if needed
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.
2019-10-29 08:42:38 -07:00
Wez Furlong
df20277d85 clippy 2019-07-06 08:18:59 -07:00
Wez Furlong
2e4214de48 fixup travis build 2019-06-14 06:40:02 -07:00
Wez Furlong
a6ff84a268 fixup fontconfig detection on centos 7
This compiles on my centos 7 machine, but I've not tried to run
the gui frontend on this system because it is headless.
2019-06-13 21:51:16 -07:00
Wez Furlong
45d378565b probably fixup build for windows 2019-05-29 12:42:20 -07:00
Wez Furlong
98e93ff3a5 Fix a build issue on fedora 30: lib vs lib64 2019-05-29 11:12:32 -07:00
Wez Furlong
660e52d309 bindgen: skip layout tests
They're specific to the host that ran bindgen, which causes the
windows build to fail if bindgen ran on linux for example.
2019-03-24 11:08:14 -07:00
Wez Furlong
45c1f5b4f3 cleanup travis config, re-enable cargo test --all
Streamline the travis deploy builds; when TRAVIS_TAG is set
we'll run `--release` builds.

Don't error out in fontconfig/build.rs if fontconfig is not
installed.  This makes it possible to `cargo test --all` again
on the mac at the cost of potentially making it harder to troubleshoot
problems with not having fontconfig installed on linux.
However: the get-deps script is responsible for installing that.
2019-03-24 08:45:28 -07:00
Wez Furlong
40844962f3 workaround dirty zlib build 2019-03-23 13:18:55 -07:00