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
c53d06bcd1
wezterm/wezterm-font/Cargo.toml

54 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
Add compile time features to allow building without vendored fonts closes: #2305
2022-09-09 18:40:05 +03:00
[features]
vendor-jetbrains = []
vendor-roboto = []
vendor-noto-emoji = []
vendor-nerd-font-symbols = []
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
[dependencies]
anyhow = "1.0"
config = { path = "../config" }
fonts: improve font name decoding freetype can't handle a wide range of encodings for font names and can return strings like `?????` when the family name is only present in the font as a non-unicode encoding, such as Chinese. This commit improves our handling of the font name table and prefers to use results from processing that over the results returned for eg: font family directly from the freetype API. refs: https://github.com/wez/wezterm/issues/1761
2022-03-26 09:27:27 +03:00
encoding_rs = "0.8"
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"
deps: upgrade finl_unicode to 1.2
2022-10-23 22:07:00 +03:00
finl_unicode = "1.2"
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"
lfucache: improve LFU algorithm and structure Do it "more properly": use intrusive list linkage to manage three indices: * hash lookup * recency * frequency eviction is frequency based, but in order to avoid things that were super hot in the past and that are no longer hot clogging up the cache, eviction will incrementally age out least recently used entries that haven't been active in the span of some number of get/put operations. Aging scales down the frequency value to reduce its strength, so an aged item isn't necessarily immediately a candidate for removal, it just makes it more likely to be picked up by the frequency based removal as it goes unused for an extended period.
2022-11-14 17:34:38 +03:00
lfucache = { path = "../lfucache" }
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
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"]}
deps: ordered-float closes: https://github.com/wez/wezterm/pull/1946
2022-05-02 07:43:22 +03:00
ordered-float = "3.0"
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"
walkdir = "2"
refactor: move color parsing into wezerm-color-types crate Resolves a little bit of the awkward duplication of color types between some of the crates by factoring them a little bit better. This is prep for allowing specifying alpha for some colors in the config.
2022-02-05 23:59:54 +03:00
wezterm-color-types = { path = "../color-types" }
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" }
wezterm: add experimental_bidi config option and very basic bidi This commit is larger than it appears to due fanout from threading through bidi parameters. The main changes are: * When clustering cells, add an additional phase to resolve embedding levels and further sub-divide a cluster based on the resolved bidi runs; this is where we get the direction for a run and this needs to be passed through to the shaper. * When doing bidi, the forced cluster boundary hack that we use to de-ligature when cursoring through text needs to be disabled, otherwise the cursor appears to push/rotate the text in that cluster when moving through it! We'll need to find a different way to handle shading the cursor that eliminates the original cursor/ligature/black issue. * In the shaper, the logic for coalescing unresolved runs for font fallback assumed LTR and needed to be adjusted to cluster RTL. That meant also computing a little index of codepoint lengths. * Added `experimental_bidi` boolean option that defaults to false. When enabled, it activates the bidi processing phase in clustering with a strong hint that the paragraph is LTR. This implementation is incomplete and/or wrong for a number of cases: * The config option should probably allow specifying the paragraph direction hint to use by default. * https://terminal-wg.pages.freedesktop.org/bidi/recommendation/paragraphs.html recommends that bidi be applied to logical lines, not physical lines (or really: ranges within physical lines) that we're doing at the moment * The paragraph direction hint should be overridden by cell attributes and other escapes; see 85a6b178cfddee94b3ddb39c26652bbd5a973666 and probably others. However, as of this commit, if you `experimental_bidi=true` then ``` echo This is RTL -> عربي فارسی bidi ``` (that text was sourced from: https://github.com/microsoft/terminal/issues/538#issuecomment-677017322) then wezterm will display the text in the same order as the text renders in Chrome for that github comment. ``` ; ./target/debug/wezterm --config experimental_bidi=false ls-fonts --text "عربي فارسی ->" LeftToRight 0 ع \u{639} x_adv=8 glyph=300 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=244 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 6 ي \u{64a} x_adv=4 glyph=363 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 9 ف \u{641} x_adv=11 glyph=328 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=240 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=278 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 17 ی \u{6cc} x_adv=4 glyph=664 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 19 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 20 - \u{2d} x_adv=8 glyph=276 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 21 > \u{3e} x_adv=8 glyph=338 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ``` ``` ; ./target/debug/wezterm --config experimental_bidi=true ls-fonts --text "عربي فارسی ->" RightToLeft 17 ی \u{6cc} x_adv=9 glyph=906 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=277 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=4.78125 glyph=272 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=241 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 9 ف \u{641} x_adv=5 glyph=329 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 6 ي \u{64a} x_adv=9 glyph=904 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=243 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=5 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 0 ع \u{639} x_adv=6 glyph=301 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText LeftToRight 0 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 1 - \u{2d} x_adv=8 glyph=480 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 2 > \u{3e} x_adv=8 glyph=470 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ; ``` refs: https://github.com/wez/wezterm/issues/784
2022-01-25 18:16:51 +03:00
wezterm-bidi = { path = "../bidi" }
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"
env_logger -> 0.10 closes: https://github.com/wez/wezterm/pull/2803
2022-11-28 07:37:25 +03:00
env_logger = "0.10"
Reference in New Issue Copy Permalink