Expedient plan for moving to read-fonts

[dfrg]

The goal is to replace ttf-parser with small diffs that don't break tests. With that in mind, I'm using the following process:

1. Replaces calls into ttf-parser with stubs that contain the simplest equivalent read-fonts code that preserves behavior. This code may not be architecturally ideal, might have performance issues and will probably be missing comments and tests.
2. Audit the new code, likely moving the bulk of it to read-fonts. Make it commented, tested and fast.
3. Implement architectural changes to match the patterns used in skrifa. Most specifically, let's support acceleration structures that aren't bound to the lifetime of font data.

The rationale for this approach is that it’ll be vastly simpler to do cleanup and architectural changes if we’re not dancing around ttf-parser (or worse, mixed ttf-parser/read-fonts) code.

ref comments in #8

[alerque]

Is there discussion somewhere about why this is being managed as a fork instead of working on the Rustybuzz code and gating the ttf-parser interactions behind a feature flag, then adding alternatives gated behind a read-fonts feature flag and requiring one or the other during transition?

If that's been considered already, can I at least ask what the current workflow is for keeping the other parts of the code in sync?

[LaurenzV]

Is there discussion somewhere about why this is being managed as a fork instead of working on the Rustybuzz code and gating the ttf-parser interactions behind a feature flag, then adding alternatives gated behind a read-fonts feature flag and requiring one or the other during transition?

I think it's because originally rustybuzz wasn't part of the harfbuzz org and RazrFalcon didn't transfer ownership back then, so they created a fork instead. And now both kind of exist here.

If that's been considered already, can I at least ask what the current workflow is for keeping the other parts of the code in sync?

Also not sure what the official policy is, but I think it would be best to make all changes to rustybuzz for now, and once harfruzz is being worked on full-time, make one big merge from rustybuzz to harfruzz, and from then on focus on just harfruzz (and deprecate rustybuzz once harfruzz is production-ready).

[behdad]

One thing also to consider is that ideally we want harfruzz API to become closer to HB, in particular, adding the hb_font_t abstraction.