wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-18 10:52:16 +03:00
Code Issues Projects Releases Wiki Activity
6ed16441c0
wezterm/wezterm-font/Cargo.toml

49 lines
1.4 KiB
TOML
Raw Normal View History

split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[package]
name = "wezterm-font"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
wezterm: update allsorts shaper The current master of allsorts supports color fonts in both bitmap and svg varieties. I'm interested to see if I can teach wezterm to render the svg based variety in a subsequent diff. First though, it's times to dust off our allsorts shaper logic. This commit updates to point to the current master of allsorts at the time of writing; there's a little bit of API fanout that makes it a bit easier to manage font fallback. The fallback logic has been improved so that we can now successfully fall back to the emoji font. The shaping logic has been improved so that we turn on the options that enable ZWJ for combining sequences of emoji, such as "man health worker". Running with the allsorts shaper enabled produces generally superior emoji/ligature substitution results compared to harfbuzz with Noto Color Emoji; the "man health worker" and the flags (eg: `flag: England`) from the subdivsion-flag section don't get substituted at all with harfbuzz, but do produce appropriate glyphs with allsorts. refs: https://github.com/wez/wezterm/issues/66
2020-11-21 03:56:07 +03:00
allsorts = { git = "https://github.com/yeslogic/allsorts.git", rev="3947164a201ab5e15d5f23204faaaaaad52531aa" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
anyhow = "1.0"
config = { path = "../config" }
refactor deps so that window can depend on wezterm-font I want to use this to render the font in the title bar
2021-06-27 05:48:06 +03:00
color-types = { path = "../color-types" }
Add `wezterm ls-fonts` subcommand At this time it just shows you the fonts that your config matches and where they came from: ``` ; wezterm -n ls-fonts Primary font: wezterm.font("JetBrains Mono", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/JetBrainsMono-Regular.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/NotoColorEmoji.ttf, FontConfig) wezterm.font("Last Resort High-Efficiency", weight="Regular", stretch="Normal", italic=false) (<built-in>, BuiltIn) When Italic=true: wezterm.font("JetBrains Mono", weight="Regular", stretch="Normal", italic=true) (/home/wez/.fonts/JetBrainsMono-Italic.ttf, FontConfig) wezterm.font("JetBrains Mono", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/JetBrainsMono-Regular.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/NotoColorEmoji.ttf, FontConfig) wezterm.font("Last Resort High-Efficiency", weight="Regular", stretch="Normal", italic=false) (<built-in>, BuiltIn) When Intensity=Bold: wezterm.font("JetBrains Mono", weight="Bold", stretch="Normal", italic=false) (/home/wez/.fonts/JetBrainsMono-Bold.ttf, FontConfig) wezterm.font("JetBrains Mono", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/JetBrainsMono-Regular.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/NotoColorEmoji.ttf, FontConfig) wezterm.font("Last Resort High-Efficiency", weight="Regular", stretch="Normal", italic=false) (<built-in>, BuiltIn) When Intensity=Bold Italic=true: wezterm.font("JetBrains Mono", weight="Bold", stretch="Normal", italic=true) (/home/wez/.fonts/JetBrainsMono-Bold-Italic.ttf, FontConfig) wezterm.font("JetBrains Mono", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/JetBrainsMono-Regular.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/usr/share/fonts/google-noto-emoji/NotoColorEmoji.ttf, FontConfig) wezterm.font("Noto Color Emoji", weight="Regular", stretch="Normal", italic=false) (/home/wez/.fonts/NotoColorEmoji.ttf, FontConfig) wezterm.font("Last Resort High-Efficiency", weight="Regular", stretch="Normal", italic=false) (<built-in>, BuiltIn) ``` refs: #347
2021-04-12 19:36:56 +03:00
enum-display-derive = "0.1"
deps: upgrade euclid -> 0.22
2020-12-10 21:03:16 +03:00
euclid = "0.22"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
freetype = { path = "../deps/freetype" }
harfbuzz = { path = "../deps/harfbuzz" }
lazy_static = "1.4"
log = "0.4"
fonts: add custom freetype stream impl The intent is to reveal more context on what's happening in https://github.com/wez/wezterm/issues/671 As a nice side benefit, this avoids the potential inability to open paths that are not utf8 or representable as c-strings on Windows. And on top of that: this enables memory mapped file IO as well, which wasn't enabled previously. This should help to reduce extraneous copies of the font in memory, have fewer open files and minimize the chances of racing with O_CLOEXEC.
2021-04-10 19:23:11 +03:00
memmap2 = "0.2"
deps: cargo update, and a couple of dependabot suggestions
2021-07-19 05:10:46 +03:00
metrics = { version="0.17", features=["std"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
mux = { path = "../mux" }
deps: cargo update, and a couple of dependabot suggestions
2021-07-19 05:10:46 +03:00
ordered-float = "2.7"
wezterm-font: introduce FontDatabase This tidies up the font-dir and built-in font management a little bit and paves the way for codepoint -> font resolution for fonts discovered in font-dirs.
2020-11-26 06:15:08 +03:00
rangeset = { path = "../rangeset" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
termwiz = { path = "../termwiz" }
thiserror = "1.0"
wezterm: update allsorts shaper The current master of allsorts supports color fonts in both bitmap and svg varieties. I'm interested to see if I can teach wezterm to render the svg based variety in a subsequent diff. First though, it's times to dust off our allsorts shaper logic. This commit updates to point to the current master of allsorts at the time of writing; there's a little bit of API fanout that makes it a bit easier to manage font fallback. The fallback logic has been improved so that we can now successfully fall back to the emoji font. The shaping logic has been improved so that we turn on the options that enable ZWJ for combining sequences of emoji, such as "man health worker". Running with the allsorts shaper enabled produces generally superior emoji/ligature substitution results compared to harfbuzz with Noto Color Emoji; the "man health worker" and the flags (eg: `flag: England`) from the subdivsion-flag section don't get substituted at all with harfbuzz, but do produce appropriate glyphs with allsorts. refs: https://github.com/wez/wezterm/issues/66
2020-11-21 03:56:07 +03:00
tinyvec = "1.1" # Note: constrained by the allsorts crate
deps: update unicode-segmentation to 1.8
2021-08-12 07:56:30 +03:00
unicode-segmentation = "1.8"
wezterm: fixup some allsorts shaping cases * Fixes `keycap 0` by plucking out the prior character for an EnclosingMark * Fixes lookahead for VariationSelector refs: #66
2020-11-21 05:44:28 +03:00
unicode-general-category = "0.3"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
walkdir = "2"
refactor deps so that window can depend on wezterm-font I want to use this to render the font in the title bar
2021-06-27 05:48:06 +03:00
wezterm-input-types = { path = "../wezterm-input-types" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
wezterm-term = { path = "../term", features=["use_serde"] }
fonts: use toast notification for missing glyph notification Popping open the config error window is a bit of overkill
2021-05-02 02:05:23 +03:00
wezterm-toast-notification = { path = "../wezterm-toast-notification" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[target.'cfg(any(target_os = "android", all(unix, not(target_os = "macos"))))'.dependencies]
fontconfig = { path = "../deps/fontconfig" }
[target."cfg(windows)".dependencies]
wezterm-font: teach gdi locator how to search for fallback fonts This commit uses a bit of DirectWrite to discover which font(s) can be used to render a set of codepoints. While hooking this up, I found that the method we were using to extract the font data didn't handle TTC data so this commit improves some parser diagnostics and handling for that. refs: https://github.com/wez/wezterm/issues/299
2020-11-26 01:53:42 +03:00
dwrote = "0.11"
wezterm: fixup win32 build for wezterm-gui changes refs: #301
2020-10-25 03:00:07 +03:00
winapi = "0.3"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[target.'cfg(target_os = "macos")'.dependencies]
wezterm-font: remove font-loader dependency This commit replaces it with the underlying core text calls on macos. refs: #337
2020-11-22 22:19:44 +03:00
core-foundation = "0.9"
core-text = "19.0"
Add shaper post-processing function This function is intended to deal with certain kinds of ligatures and certain combining sequences that don't have corresponding glyphs. It isn't hooked up to the gui yet, but does have unit tests that are probably mostly correct. refs: https://github.com/wez/wezterm/issues/478
2021-02-22 20:19:05 +03:00
[dev-dependencies]
update k9 to 0.11.0 to make it work with rustc@1.51.0 1.51.0 no longer takes non string literals in `panic()`. k9@0.11.0 fixes that
2021-03-25 20:32:31 +03:00
k9 = "0.11.0"
Add shaper post-processing function This function is intended to deal with certain kinds of ligatures and certain combining sequences that don't have corresponding glyphs. It isn't hooked up to the gui yet, but does have unit tests that are probably mostly correct. refs: https://github.com/wez/wezterm/issues/478
2021-02-22 20:19:05 +03:00
pretty_env_logger = "0.4"
Reference in New Issue Copy Permalink