david-vanderson
Figure out accessing system fonts
https://github.com/david-vanderson/dvui/issues/121#issuecomment-2362212259 points out that for many languages the default fonts we ship with dvui don't support enough characters.
Unsure how this should work, but it seems like we need some way to pull in system fonts at runtime, and either use them directly or as fallback when the built-in font doesn't have the characters. This would be optional so apps that only want the fonts they choose to bundle can opt out.
We can load ttc/ttf at runtime. That's what nearly every graphical application does, I think.
- rasterization: most type faces are bezier paths. Most, as in not color emoji font, not svg font.
- hinting: opentype text without hinting looks awful.
I am overwhelmed by the sheer number of topics brought up recently. I feel like using Github issue to track potential features is getting wonky. Since features depend on each other, it might be better to have the textual description of each issue saved somewhere else where we can edit collaboratively.
Example using git repo itself to store docs: https://codeberg.org/VnPower/PixivFE/src/branch/v2/doc . The dev directory is for devs.
At the very bare minimum, every feature need to list its dependencies, which are features that may not exist yet.
Yes that sounds right - we can have either compiled-in fonts or load them at runtime (or both). We'll normally have freetype2 compiled in, which will handle rasterization and hinting for us. In some places (web), we're currently using stb_truetype for rasterization, which doesn't have hinting.
I'm also feeling a bit overwhelmed by the number of open issues we have, but I think it speaks to the growing usefulness of dvui. Using github issues seems to be what people expect, so let's live with it a bit more and see. If it is getting out of control we'll figure out something.
May I suggest either
- Using issue labels to categorize issues better or
- Using Github Projects to organize related issues and topics
There are many highly active github repos with thousands of issues - which shows that is it possible to scale the issues system as a project grows
The usage of a dev directory also seems like it could work. Then issues can be solely for usage by dvui users. The main problem I would see with this approach is that discussion on things becomes more difficult, because you can't really have a conversation in a text document
Perhaps we could start by using some labels like
- Planned/Accepted (Contributors plan to implement this)
- Bug
- Enhancement
- Low Priority
- High Priority
Labels could be useful. My preference would be for the labels to describe what action we are likely to take. So maybe like "discussion", and "planned" (meaning enough details are sorted that we could start trying to implement it). I think that covers all the existing issues?
I closed #149 after finding that fonts were the main source of excess size in web-test.wasm.
The web backend should be able to load fonts at runtime like the other backends, and then we can slim down the list of compiled-in fonts.
I think I finally have a decent plan for fonts. It has multiple levels:
1. Compile and run time font file loading This supports the usecase of any application that knows what fonts it will use. This covers
- simple app with a few embedded fonts
- game that loads a font at runtime from a resource file
dvui already supports this, but the api can be better. The demo has a prototype that can load a given ttf file. Web demo loads a ttf file from hardcoded url.
2. System font enumeration Support letting a user pick from fonts already on their system. This covers
- rich text editing
- slideshows
- theme editing
We would need mutliple OS-specific backends for this functionality, but it is limited to selecting a single font.
3. Font fallback Add css-like font selection, where the app/user can ask for a general kind of font with fallback options and dvui would try to load a "best fit" font it could find on the system.
4. Glyph fallback If a unicode codepoint (or grapheme cluster if we get there) is not present in the specified font, then (if the app opts in) dvui would try to load a glyph from a fallback font.
In #559 @phatchman pointed out that we'd like an easy way to get the "bold" or "italic" version of a base font. I'm not sure where that falls - it seems like it should go in "Font fallback", but also makes sense even at level 1 where an app would preload everything.
Bold and italic fonts are often separate files in OpenType/TrueType. https://www.freedesktop.org/software/fontconfig/fontconfig-user.html
A font family can contain many variants, including multiple bold and multiple italic ones.
i.e. A font family contains many files.
dvui then need to handle multiple fallback paths. Each font style + family is a path.
regular serif -> bold serif -> emoji bold serif -> regular serif -> emoji
I think we should have a program that copies font files from system to ... say zig-out during build time ... and generate definition files based on font-config fc-list.
See fc-list -f "%{family} | %{style} | %{file}\n"
Is there a workaround to display unsupported characters? Or the only way is to wait until this issue resolved? I'd really like to display і, ґ, ї, but only Open Dyslexic and Pixelify can show those chars.
Is there a workaround to display unsupported characters? Or the only way is to wait until this issue resolved? I'd really like to display
і,ґ,ї, but only Open Dyslexic and Pixelify can show those chars.
There is no current font fallback logic outside of displaying the fallback character. You'd need to pick a font that supports all the characters.
Is there a workaround to display unsupported characters? Or the only way is to wait until this issue resolved? I'd really like to display
і,ґ,ї, but only Open Dyslexic and Pixelify can show those chars.
Sorry - the only current way is like @RedPhoenixQ says - to bundle or load a font with those glyphs. The web demo loads a Noto font dynamically, and the examples bundle the Noto font into the executable.
Let us know if you are having trouble bundling or loading (whichever you need).
Oh, sorry I didn't understand how to load a font, but get it now. I tried .Noto predefined font, but it does not display the characters above on Linux+sdl3.
Loading a custom Noto.ttf works!
Oh, sorry I didn't understand how to load a font, but get it now. I tried
.Notopredefined font, but it does not display the characters above on Linux+sdl3.Loading a custom Noto.ttf works!
Horay!