search

RazrFalcon / rustybuzz

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

Port fallback shaper. #10

Closed laurmaedje closed 3 years ago

laurmaedje commented 3 years ago

Since I'm excited to use this in a full-Rust WASM scenario, I decided to try and tackle one of the things on the roadmap that were marked as easy. I tried making the most straightforward, parallel adaption of the original C++ to make it not too hard to review. (Part of this is that I kept the order of functions as originally, even though I guess in Rust the general -> specific order is more common than the C-compiler-inflicted specific -> general.)

Some things I weren't totally sure about, I marked these with NOTE(laurmaedje). One particular thing I hope I didn't confuse are the Modified and Canonical combining classes.

RazrFalcon commented 3 years ago

Thanks! I didn't thought anyone would work on this. And I really don't have to time for this project right now, sadly.

Since all tests are passed, I don't have any real complains.

This branch is never tested.

Yes, this is pretty common. You can remove all those comments. We can check it via cargo tarpaulin at any time.

If you plan to write any tests - write them to the harfbuzz first. I don't want to have any rustybuzz-specific tests. And it will benefit both projects.

laurmaedje commented 3 years ago

I removed all those notes. Also good to know that I can use cargo tarpaulin.

Now, what I need to know: Would you have the time to review more PRs here (and maybe in ttf-parser for table-related things) or should I refrain from doing more work here at the moment?

alerque commented 3 years ago

I don't know exactly how useful I might be since I'm low on bandwidth and don't have a current project where I'm actively using this, but I am fairly interested in this approach to getting a Rust port and feel like pursuing it will be good for the shaping ecosystem in general, benefiting both Harfbuzz upstream and downstream projects. I actually started tinkering with the approach while this project was still in the now deprecated 'old' phase. If there is something I can do let me know. Even if it's just another pair of eyes scanning PRs. My Rust isn't super advanced but it's better than my C!

RazrFalcon commented 3 years ago

@laurmaedje Thanks. Yes, I do have time for reviews. I just can't work full-time on this project right now.

Moreover, I would be glad if someone would help me with this project. This is mostly a tedious rewrite with minimal changes. And you can take any task from the roadmap. The only unpublished thing I have is kerx support (which is very similar to mort/morx and should be done first). And this is basically all the Apple tables support we need. The real problem is testing, as mentioned in the readme.

As for the TrueType tables support, I think all the remaining tables should be implemented on the rustybuzz side first, and then moved to ttf-parser, if we would be able to figure out any sane API. For example, I have no idea what kind of API we could have for GSUB/GPOS parsing, because of how tight it works with hb_buffer_t in hb. But first, you should use the next branch (a bit outdated right now) of ttf-parser, which has the parser module public.

Feel free to ask any questions.

RazrFalcon commented 3 years ago

@alerque Thanks. Anything would help. But I would say that testing is the most crucial part. Yes, HB has tons of tests, but sadly, this is not enough. Shaping is way too complicated.