search

harfbuzz / rustybuzz

A complete harfbuzz's shaping algorithm port to Rust
MIT License
551 stars 37 forks source link

Coordinate with otf-fea-rs? #9

Closed twardoch closed 4 years ago

twardoch commented 4 years ago

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.

RazrFalcon commented 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).

twardoch commented 4 years ago

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 :)

wrl commented 4 years ago

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.

(ref https://github.com/wrl/otf-fea-rs/issues/1)

RazrFalcon commented 4 years ago

Sure. I'm closing this, since there are no overlapping code in those project right now.

twardoch commented 4 years ago

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 :)

twardoch commented 4 years ago

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

RazrFalcon commented 4 years ago

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.