Closed twardoch closed 4 years ago
Well, rustybuzz is just a harfbuzz port. So I'm doing the same work harfbuzz does without much changes (except parsing itself).
Right! I probably meant mostly the other way around. otf-fea-rs needs some font libraries (not sure how it works), and it's a relatively young project. I think the goal is to allow instant rebuilding of features from the text source.
I can imagine some benefits of using both, though I cannot say right away what they are :)
Hey! Will respond over here.
While there is certainly some common ground between otf-fea-rs and RustyBuzz, I don't think the overlap is massive. I think the biggest thing would be the parsing/loading of the more advanced OpenType tables (notably, GPOS and GSUB). The Runebender project is already interested in utilising some of the otf-fea-rs code for this, so in the short/mid-term I will be breaking those components out into a reusable state.
Of note, though, is that since otf-fea-rs is designed to both read and write TTF/OTF files, the data model is not as efficient as it could be from a read-only point of view. For example, ttf-parser is zero-allocation, which otf-fea-rs cannot be without splitting the read and write data models. With that said, I'm of course interested in using the most optimal data structures while balancing these concerns.
@RazrFalcon let me know if you're interested in using the otf-fea-rs TTF/OTF loading code and/or in-memory representation.
Sure. I'm closing this, since there are no overlapping code in those project right now.
Thanks for looking into it, I just wanted to make sure that potential benefits (of which I know little) don't go unnoticed by you guys :)
Here's a use case that shows why, in principle, it makes sense to combine a OpenType Layout engine with an OpenType feature compiler: https://github.com/simoncozens/namvezvez/blob/master/README.md
It's great to see alternative implementations, but that one supports like 1% of what harfbuzz do. Also, shaping is a very performance-sensitive operation. Python will be slow as hell.
https://github.com/wrl/otf-fea-rs/ is a Rust-based compiler of FEA into GSUB/GPOS, while https://github.com/RazrFalcon/rustybuzz is a Rust-based OT shaper.
Perhaps @wrl and @RazrFalcon could somehow coordinate so that the two libraries can interoperate. No specific idea yet but I can well imagine this to be beneficial.