Figure out accessing system fonts

[david-vanderson]

#121 (comment) 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.

[iacore]

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.

[david-vanderson]

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.

[VisenDev]

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

[VisenDev]

Perhaps we could start by using some labels like

• Planned/Accepted (Contributors plan to implement this)
• Bug
• Enhancement
• Low Priority
• High Priority

[david-vanderson]

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?

[david-vanderson]

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.

[david-vanderson]

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.