wez
fonts: Allow to build GUI without vendored (built-in) fonts
Bundling fonts into the binary is ~~completely~~ unnecessary ~~and inadequate~~ when WezTerm is installed using a package manager, e.g. from a Linux distribution repository. The package maintainer can declare the needed fonts as dependencies of the package, so they can be installed with the WezTerm package into a standard location, available for all applications.
This commit adds a new feature gate "vendored-fonts" into wezterm-font and wezterm-gui. If this feature is disabled, ~~load_built_in_fonts() in parser.rs is replaced with a no-op function and no fonts are included in the binary.~~ only LastResortHE-Regular.ttf is included in the binary (according to https://github.com/wez/wezterm/pull/2305#issuecomment-1194779072, WezTerm would panic if this font is not found). WezTerm will simply use the system's font API (fontconfig on Linux) to locate the default fonts.
This feature is enabled by default in wezterm-gui, so nothing will change, unless explicitly disabled.
completely unnecessary and inadequate when WezTerm is installed using a package manager
Please mind your tone: that's your opinion rather than a fact. There is nothing inadequate about vendoring the fonts. It may be potentially redundant with the user's installed fonts, but there is nothing wrong with vendoring as your tone implies.
In addition, there are two fonts that no one distributes and that not having available will negatively impact wezterm:
Symbols-Nerd-Font-Mono.ttf(will degrade user experience without it)LastResortHE-Regular.ttf(will actually panic without it when a font is not found)
In addition, your proposed change introduces non-determinism when running tests: the tests rely on loading the vendored fonts and with your change, will now fail if the user has not installed those fonts, or may change their behavior if a different version of those fonts are installed.
Please mind your tone: Please mind your tone: that's your opinion rather than a fact.
I’m sorry, but bundling 15 MiB of fonts into a program binary is really not considered a good practice, at least not for software to be included in Linux distributions. I’m an Alpine Linux developer, but this applies to all distros. It may be legitimate in other use cases though, I don’t dispute that!
there are two fonts that no one distributes and that not having available will negatively impact wezterm: Symbols-Nerd-Font-Mono.ttf (will degrade user experience without it)
That’s not entirely true.
Arch Linux also provides this font ttf-nerd-fonts-symbols-mono (actually, it’s not the Mono variant as the name suggests, but this should be fixed in the package). Alpine Linux distributes this font (since yesterday): font-nerd-fonts-symbols-1000em. I’ve packaged it specifically for WezTerm.
Moreover, this font is not necessary, or to put it another way, it’s not the only option. The user can install and use any patched Nerd Font (these are available in multiple Linux distros), right?
You could also just add these fonts into the release tarballs and instruct users to install them into the standard font location on their system (~/.local/share/fonts on Linux). Package maintainers will take care of it and package them for the users. That’s how Linux distributions work.
LastResortHE-Regular.ttf (will actually panic without it when a font is not found)
Why does it panic? Why is this font needed on a Linux system with Fontconfig that automatically handles fallbacks and missing glyphs?
the tests rely on loading the vendored fonts and with your change, will now fail if the user has not installed those fonts or may change their behavior if a different version of those fonts are installed.
Can you please elaborate? Are there more tests that depend on built-in fonts? I modified one test that depended on the built-in fonts, but in a way to load the fonts from assets/fonts.
I’ve rephrased the commit message and included LastResortHE-Regular.ttf even when bundled-fonts is enabled. However, I still wonder why this font is needed.
The last resort font is used as a last resort when no matching glyph is found. The code relies on it being last in the fallback list so that it can guarantee to show a placeholder glyph in that situation.
Because glyph resolution is async, these placeholders can appear briefly while the system is queried to locate fallbacks.
I’ve applied the suggested changes and rebased.
The last resort font is used as a last resort when no matching glyph is found.
When no matching glyph is found, the .notdef glyph should be rendered. That’s a standard behaviour specified in TrueType and OpenType and what every software I know does.
The Last Resort font is not only big, but it makes it difficult for people to recognize that what they are seeing is actually a placeholder glyph. Just look at the examples in the description and imagine these glyphs in 13px size on a FullHD monitor.
The code relies on it being last in the fallback list so that it can guarantee to show a placeholder glyph in that situation.
Why does the code handle this and make such assumptions at all? On what platforms is this needed? I’m almost certain that Linux doesn’t need this, that’s the Fontconfig’s job. If it’s needed on some other platform, why is this code enabled even for Linux builds?
Your tone is still a problem. You clearly have strong opinions about how you think things should be done, but the way that you are presenting them comes across as challenging and argumentative.
I just don't have the time or energy to mount a defense, and the fact is that I don't have to justify any of my choices or decisions to you or anybody else.
How you have come across so far is as though you've entered my home, told me how you think that what I've done is wrong, unnecessary, inadequate, bloated and made demands on how to make it conform to your desires without considering what my own goals or desires are.
It's not a good way to foster collaboration. If that were to happen in real life, I would evict you from my home and choose to avoid interacting with you.
Please adjust your tone if you wish to continue to collaborate and contribute!
Your tone is still a problem.
Please consider that I’m not an American, English is not my native language and I have a different cultural background. I don’t know why you find my tone problematic, I’m just trying to make an argument, that’s all.
Can we please focus on the technical matter instead of diplomatic excercises? I’ve explained why the Last Resort font is problematic, what do the specs say and how it is commonly handled in other software. My interest is to improve WezTerm for the users, not to argue with you.
@jirutka: Some of the questions, or arguments, in and of itself, is "okay". But, when read everything together, the tone doesn't feel right. It could be that you're not able to convey what you actually intend (I am also a non-native speaker, btw). What I suggest you is to just keep write only "needed" stuff and avoid everything else. For instance, the last sentence in the post above just doesn't feel right (to me). Like I said above, in and of itself, it's okay, but when I read it as a whole, it doesn't feel right. :-(
Another import thing to note is, except for some stuff, everything is done by @wez. He is also the only dev/maintainer. He is spending his time, and more importantly, he shouldn't feel unpleasant when working on this. So some stuff that feels alright to us, may not feel the same to him, because, in the end he is the only dev, and also by doing so, he can focus on higher-priority stuff. This is also another reason why I felt your last sentence doesn't feel good. We can make suggestions, requests, etc., but can't, and shouldn't(!) dictate him how to do. If someone doesn't like the decisions he make, they can fork this. That's just how FOSS works.
