Port resvg to harfrust

[nicoburns]

Changes made

• Replaces rustybuzz with harfrust
• Takes a direct dependency on ttf-parser (which was previously being imported via rustybuzz)

Notes

• This is failing 19 tests. These probably need to be manually checked, and I don't think I'm qualified!
• This requires an MSRV bump from 1.65 to 1.75
• We may want to hold off on merging this until we can switch the rest of the ttf_parser code to skrifa, otherwise users will be paying for both ttf_parser and read-fonts.
• Even then, this will represent a binary size bump for users of resvg. According to cargo-bloat (not the most accurate):
  • harfrust and rustybuzz are both ~250kb
  • ttf_parser and read-fonts are both ~100kb
  • However, ttf_parser includes the metrics outlining functionality of skrifa. And skrifa is another ~250kb.

[LaurenzV]

Yeah I think we first have to figure out how to deal with fontdb before doing anything with resvg. I don’t think RazrFalcon would want to switch it, and I’m not sure that fontique supports everything we need?

[RazrFalcon]

It's an interesting experiment, but I don't see a point in it. Is there a reason in switching to harfrust?
Last time I have checked it was still a beta, while rustybuzz (with all its faults) is a pretty robust solution.

PS: even if harfrust is faster, it doesn't matter either, because shaping isn't a bottleneck, lack of glyphs caching is.

[RazrFalcon]

Oh wait, it depends on proc-macros/syn?! Burn it with fire! No proc-macros in resvg.

[LaurenzV]

Last time I have checked it was still a beta, while rustybuzz (with all its faults) is a pretty robust solution.

harfrust is rustybuzz, just with ttf-parser switched out by read-fonts. It passes all the same tests, so it should be no less robust than then rustybuzz.

Is there a reason in switching to harfrust?

The reason is that going forward, (most likely) no one will be continually developing ttf-parser/rustybuzz, while harfrust will be actively maintained.

[RazrFalcon]

I would suggest to come back to it in a year. No rush.

And once again, proc-macros are no go. We have to figure out that one as well.

[xStrom]

Shouldn't this (and the other rust-version modifications) be 1.75.0 not 79?

[xStrom]

Last time I have checked it was still a beta

Not sure about 'beta' type labels, but the first release (0.1.0) of HarfRust happened on June 10, marking a significant milestone.

It's an interesting experiment, but I don't see a point in it. Is there a reason in switching to harfrust?

For an immediate effect, it seems to be far more compliant when tested against the HarfBuzz test suite.

To quote Chad:

We’re still mulling over some public API changes and need to do some serious performance work but this is fully backed by fontations, up to date with HarfBuzz 11.2.1, and passes a significantly larger portion of the HB test suite than RustyBuzz: latest CI shows 5911 tests passing for HarfRust vs 2267 for RustyBuzz.

And the HarfRust introduction post by Behdad contains the following claim:

At the time of this writing, HarfRust passes most of the HarfBuzz shaping test suites, failing just 23 tests out of more than 6,000.

---

Moving forward, HarfRust will receive active development and continuous sync with HarfBuzz, while RustyBuzz is likely to only see critical fixes.

[RazrFalcon]

latest CI shows 5911 tests passing for HarfRust vs 2267 for RustyBuzz.

Apples and oranges, but sure.

Either way, proc-macros is the current major roadblock.

[mattfbacon]

@RazrFalcon Seems like the proc-macros are coming from font-types which uses bytemuck and serde derive macros. Do we want to talk to them about converting to manual implementations?

[RazrFalcon]

@mattfbacon if it's an easy fix - sure.

[mattfbacon]

No it wouldn't be at all, since the bytemuck derive macros generate unsafe code so they would need to allow unsafe code back into the codebase.

But what is your plan here? Earlier you said wait, but for what?

[RazrFalcon]

No it wouldn't be at all, since the bytemuck derive macros generate unsafe code so they would need to allow unsafe code back into the codebase.

I would call it easy. It's not like the code deeply depends on proc-macros.

But what is your plan here? Earlier you said wait, but for what?

Adoption, etc. I don't see a point/reason in switching to 0.1. Especially if we would keep ttf-parser around. It just doesn't make any sense.

[Shnatsel]

There are derive helpers based on macro_rules! rather than proc macros: https://matx.com/research/rules_derive

It is likely possible to implement an alternative derive for bytemuck traits using such helpers. These can then be published as a separate crate such as bytemuck_derive_lite to avoid any potential backward compatibility issues with the proc macro implementation.