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

Support woff2 #122

Open
stephanemagnenat opened this issue May 8, 2023 · 3 comments
Open

Support woff2 #122

stephanemagnenat opened this issue May 8, 2023 · 3 comments

Comments

@stephanemagnenat
Copy link

stephanemagnenat commented May 8, 2023

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
Copy link
Collaborator

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

@inferiorhumanorgans
Copy link
Contributor

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
Copy link
Collaborator

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.

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