wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-28 07:55:03 +03:00
Code Issues Projects Releases Wiki Activity
249f9dfe29
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: metrics 0.15 -> 0.16, cargo update
2021-05-24 17:57:03 +03:00
metrics = { version="0.16", 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: ordered-float 2.1 -> 2.5 closes: https://github.com/wez/wezterm/pull/831
2021-05-31 10:17:18 +03:00
ordered-float = "2.5"
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
wezterm: improve shaping of emoji This is one of those massive time sinks that I almost regret... As part of recent changes to dust-off the allsorts shaper, I noticed that the harfbuzz shaper wasn't shaping as well as the allsorts one. This commit: * Adds emoji-test.txt, a text file you can `cat` to see how well the emoji are shaped and rendered. * Fixes (or at least, improves) the column width calculation for combining sequences such as "deaf man" which was previously calculated at 3 cells in width when it should have just been 2 cells wide, which resulted in a weird "prismatic" effect during rendering where the glyph would be rendered with an extra RHS portion of the glyph across 3 cells. * Improved/simplified the clustering logic used to compute fallbacks. Previously we could end up with some wonky/disjoint sequence of undefined glyphs which wouldn't be successfully resolved from a fallback font. We now make a better effort to consolidate runs of undefined glyphs for fallback. * For sequences such as "woman with veil: dark skin tone" that occupy a single cell, the shaper may return 3 clusters with 3 glyphs in the case that the font doesn't fully support this grapheme. At render time we'd just take the last glyph from that sequence and render it, resulting in eg: a female symbol in this particular case. It is generally a bit more useful to show the first glyph in the sequence (eg: person with veil) rather than the gender or skin tone, so the renderer now checks for this kind of overlapping sequence and renders only the first glyph from the sequence.
2020-11-24 00:45:38 +03:00
unicode-segmentation = "1.7"
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