Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asynchronous font loading #25

Open
chearon opened this issue Jan 8, 2025 · 0 comments
Open

Asynchronous font loading #25

chearon opened this issue Jan 8, 2025 · 0 comments

Comments

@chearon
Copy link
Owner

chearon commented Jan 8, 2025

Right now dropflow is centered around font buffers. When you call registerFont with a file path or URL, it will load it right away with fetch (in node and the browser) for two reasons:

  1. To get metadata in the font for font selection (family, weight, etc in the OS/2 table)
  2. So that layout can be sync while we walk the fallbacks

I remembered today that the whole point of @font-face and FontFace is that you can specify metadata (family, weight, etc) without loading the file. That's how OS APIs work too: FontConfig doesn't open every TTF when you query it; it has (metadata, file) pairs cached. So I might want to require metadata in registerFont and remove the metadata-reading code entirely.

The obvious upside is that you can register tons of fonts to cover potentially all languages for cheap. The current flow.loadNotoFonts could be replaced with flow.registerNotoFonts which only has to be called at startup.

(1) is easy and (2) is easy when running in node with sync APIs, but is harder for async (browser). Layout has to be suspended until fallbacks are done. I previously wanted to avoid this, but now it sounds interesting. Suspending layout might tie in with fragmentation (#7) which also suspends layout.


Buffers should always be allowed for those who want sync layout.

Node-canvas could be updated to stop reading fonts at registration too (as part of the font stack rewrite: Automattic/node-canvas#2476).

One potential problem in being aligned with the standards is that CSS font selection doesn't select based on content language; that's done in the "opaque" OS fonts. I could either remove that feature, as it's probably not used much, or I could add a nonstandard field.

I could also add some utility function to generate metadata/FontFace fields by reading the file, if I want to keep all of that. But that would probably not be used much either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant