You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
To get metadata in the font for font selection (family, weight, etc in the OS/2 table)
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.
The text was updated successfully, but these errors were encountered:
Right now dropflow is centered around font buffers. When you call
registerFont
with a file path or URL, it will load it right away withfetch
(in node and the browser) for two reasons:layout
can be sync while we walk the fallbacksI remembered today that the whole point of
@font-face
andFontFace
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 inregisterFont
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 withflow.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.The text was updated successfully, but these errors were encountered: