What's fontations' WASM story?

[thesmartwon]

I ask because I find opentype.js and fontkit lacking in subsetting variable fonts compared to harfbuzz/Klippa.

Klippa works without any code changes with wasm32-wasip2 but needs code changes to target wasm32-unknown-unknown.

[LaurenzV]

I ran cargo build -p klippa --target wasm32-unknown-unknown and it seems to work fine, not sure what issues you are having?

[thesmartwon]

Yes, wasm32-unknown-unknown, builds, but it's not useful because it cannot use OS syscalls like wasip1 or wasip2 can. I'd love to see an opentype.js like library here:

~/src/fontations(main)$ wasm2wat target/wasm32-unknown-unknown/release/klippa.wasm | grep export
  (export "memory" (memory 0))
  (export "main" (func $main))
  (export "__data_end" (global 1))
  (export "__heap_base" (global 2))

...and some JS glue code, so it can be consumed like this:

import { readFont, writeFont, subsetFont } from "@fontatations/klippa";

const bytes = await fetch("https://your-font").then(r => r.arrayBuffer());
const font = readFont(bytes);
console.log(font.tables, font.metrics); // Skrifa API
const subset = subsetFont(font, { unicodes: "0-7a" }); // Klippa API
const outBytes = writeFont(subset);
console.log(outBytes); // for the user to fs.writeFile or download in a browser

...published to NPM so I npm install @fontations/klippa and use it from a web browser and NodeJS. The bindings and publishing require code changes using something like wasm-bindgen and wasm-pack.

I understand if the team is completely uninterested in maintaining a WASM API because they are focused on shipping HarfRust. Perhaps a better issue title is "What WASM API should fontations export to what registry?"

I can can tell there's some interest thanks to the CI job that confirms it builds. I'm just wondering what @cmyr and @rsheeter's reason was for adding that check in #163. Did they eventually want to add 1st party upstream bindings? Or did they want to make sure 3rd party downstream bindings continue to be possible?

[thesmartwon]

I've made a 3rd party downstream binding for Klippa and published it.

If you're interested in upstreaming these changes, please let me know I'll submit a PR.

I think it'd be nice to add bindings for skrifa since I'm still relying on the inferior opentype.js.

[rsheeter]

For #163 I think we had wasm use of http://github.com/googlefonts/fontc in mind to enable use in web-based font editors.

[rsheeter]

klippa is actively in development, I don't believe anyone has gotten to ensuring it's wasm-friendly yet.

[cmyr]

My recollection of #163 was mainly that we anticipated wasm use cases at some point in the future, and wanted to make sure we weren't landing changes that would make that future work difficult.

In any case I believe that wasm builds are being used in some places, at least experimentally? I believe @simoncozens has written a few utilities of this sort.

[thesmartwon]

to enable use in web-based font editors.

Web-based font editors would be amazing!

klippa is actively in development, I don't believe anyone has gotten to ensuring it's wasm-friendly yet.

I just refactored the Klippa CLI to call a single #[wasm_bindgen]'ed function and then fought the compiler. I learned tsify is great for not only generating Typescript definitions (which is essential for autocomplete), but also allows serde'd structs to cross the WASM boundary. I hid the entirety of WASM support behind a feature flag in case you want to upstream it.

I stopped at designing an object oriented JS API for skrifa. I found it hard to decide how low-level the API should be.

we anticipated wasm use cases at some point in the future

Thank you! Today I reap the rewards of your decision.

In any case I believe that wasm builds are being used in some places, at least experimentally? I believe @simoncozens has written a few utilities of this sort.

Please do share @simoncozens!

[rsheeter]

I believe https://github.com/counterpunchspace/editor is one example

[simoncozens]

I've used fontations WASM in a number of places:

• Shaperglot for showing language coverage of fonts. (wasm library and JS app)
• Fontspector for general font QA. (wasm library and JS app)
• Diffenator3 for font diffing. (wasm library and JS app) This one uses typescript_type_def to export the check result structs into TypeScript.
• and yes, Counterpunch uses a wasm library to build fonts on the fly while they're being edited.

Counterpunch wraps fontc, but it does so through the babelfont source representation library. You can also call fontc directly over the web (https://github.com/simoncozens/fontc-web). babelfont also exports its own structs to TypeScript. I tried a few different libraries, none of which really did what I wanted and settled on my own fork of typeshare instead.

In all of these cases, I'm not using WASM registries but I'm just statically compiling some Rust code into a big WASM blob. A WASM-based fontations API would be interesting, but if you have one, I don't know why you wouldn't just keep writing Rust and compile it all together at the end.

[thesmartwon]

I tried a few different libraries, none of which really did what I wanted and settled on my own fork of typeshare instead.

What's the difference between tsify and typeshare? Is one more suitable for fontations?

In all of these cases, I'm not using WASM registries but I'm just statically compiling some Rust code into a big WASM blob.

I also researched WASM registries and agree they aren't quite there yet. Should fontations release a WASM API I'd prefer a big blob.

A WASM-based fontations API would be interesting, but if you have one, I don't know why you wouldn't just keep writing Rust and compile it all together at the end.

npm i foo is a whole lot easier than setting up a Rust toolchain, learning wasm_bindgen, and running the Rust compiler. I believe that's why opentype.js and fontkit are so popular.