Figure out accessing system fonts

[david-vanderson]

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.

[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.