Support woff2

[stephanemagnenat]

Hello,

Is there planned support for the woff2 format? For example, allsorts supports it. This format is convenient to embed fonts, for example in games.

kind regards

[RazrFalcon]

Plans - yes, but no timeline. It will be done when it will be done.

[inferiorhumanorgans]

I wonder if it would be more appropriate to put WOFF support in a separate crate (or at least outside of Face/RawFace). I'm just spitballing here but…

WOFF Considerations

• Dependencies (brotli, zlib). There are pure rust implementations of both, but this is still a big first step.
• Heap allocation. It's certainly possible to inflate stuff in a no-std environment and/or without heap allocations, but it's that much more archaic.
• WOFF1 compresses each table individually, so it's probably not too intrusive to track whether a table should be inflated and use something like a ZlibStream struct.
• WOFF2 encodes everything as one brotli stream after optionally applying some per table transformations. This is different enough there's a risk of creating spaghetti code.
• A separate struct could simply handle the table lookup and inflation and pass the "raw" inflated data back to the appropriate ttf-parser structs. At that point it's probably (maybe?) worth extracting most of Face into a trait for ease if interoperability.

[RazrFalcon]

My approach would be to have a separate WOFF to TTF converter crate. I don't see much benefits of having WOFF support directly in ttf-parser. But I haven't looked deep enough into it.

It definitely feels like something that should not belong in ttf-parser.

[Downchuck]

The woff2 crate could use some attention to bring it up to the latest rust stable:
https://crates.io/crates/woff2 - https://github.com/Cimpress-MCP/woff2-rs

[nicoburns]

I have ported https://github.com/google/woff2 (which is the C library browsers use for WOFF2 and is what the woff crate provides bindings to, but is not the same as the Rust woff2 crate) as https://github.com/nicoburns/wuff (and added a small amount of code to allow it to also decode the much simpler WOFF1).

This will output an otf/ttf, so you should be able to combine it with ttf-parser pretty easily.

[yisibl]

Thank you for your efforts on this, but I believe we may also need to compare the performance of the C++ version(google/woff2).

[stephanemagnenat]

Thank you for your efforts on this, but I believe we may also need to compare the performance of the C++ version(google/woff2).

Note that for WASM targets, even a lower-performance implementation might be valuable, due to the easier compilation process than mixed Rust+C++ code on WASM. Of course, good performance is always welcome :-)

[yisibl]

@stephanemagnenat Of course, a pure Rust implementation holds significant value, particularly in terms of memory safety. For font rendering, Chrome has already migrated to fontations, and I believe woff2 will follow suit in the future.

In this regard, @rsheeter might offer some insights.

Regarding compiling C++ libraries to Wasm, the napi-rs ecosystem is already quite mature. Here's the Wasm version:
https://www.npmjs.com/package/@napi-rs/woff-build-wasm32-wasi