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

Building for WebAssembly #70

Open
waywardmonkeys opened this issue May 31, 2024 · 6 comments
Open

Building for WebAssembly #70

waywardmonkeys opened this issue May 31, 2024 · 6 comments

Comments

@waywardmonkeys
Copy link
Contributor

Building for WebAssembly targets with default features (read: system) is broken as there isn't an implementation for WebAssembly.

  • Should crates using fontique build with no-default-features and then enable system on all but WebAssembly?
  • Should the null backend be enabled for WebAssembly for the system feature? (Seems like it goes against the idea of a system feature.)
  • Should system not be enabled by default and let consuming crates enable it?
  • Something else?
@xorgy
Copy link
Member

xorgy commented Jun 4, 2024

system is the main point of fontique, so it being default makes sense, but that leads to the issue you describe.
There is also the issue of how to make a useful collection at all in WebAssembly, which I think would probably involve a considerable amount of support from the JavaScript side, or inlining a font into the wasm module (not necessarily the greatest solution either).

@waywardmonkeys
Copy link
Contributor Author

There is https://developer.mozilla.org/en-US/docs/Web/API/Local_Font_Access_API (only currently supported in Chrome and Edge 103 and later, but not Chrome for Android) ... but that would require having async APIs for WebAssembly.

@xorgy
Copy link
Member

xorgy commented Jun 5, 2024

Well, may not require async APIs for wasm, but rather that the loader take care of that stuff before starting the module (or that calls for the system fonts involve waiting). I was not aware that the Local Fonts API had rolled out to any stable browsers!

@xorgy
Copy link
Member

xorgy commented Jun 5, 2024

Looking into this, apparently it gives you the font data as Blob, which unfortunately can not be mapped zero-copy into wasm memory (at least, not explicitly); so probably the useful way to implement this would be some sort of limited font library selected by the host and copied into the wasm memory.

@xorgy
Copy link
Member

xorgy commented Jun 6, 2024

Looking into it further, the Local Font Access API has to prompt for permission in a browser, and the message used is something about ‘creating high fidelity content’. If you're building something other than a graphics editor or a tech demo, then presumably a lot of people will click block on this and break your app.

@torokati44
Copy link

FWIW: Aside from Chrome, the promise of this working well in either Firefox or Safari is not particularly rosy: mozilla/standards-positions#401 (comment)

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

3 participants