rustybuzz deprecation

[jackpot51]

Rustybuzz has been marked as deprecated: RazrFalcon/rustybuzz#74

At this time my plan is to fork rustybuzz into a module in cosmic-text, unless one of two things happen:

1. It can be demonstrated that swash shaping can be integrated into cosmic-text and passes the universal declaration of human rights translations test. To clarify my comment on the issue, as I understand it, swash shaping is not as feature complete as rustybuzz and a regression in capabilities would not be acceptable for cosmic-text

2. rustybuzz can be moved to an organization that has similar goals to cosmic-text: high accuracy, and a gradual movement towards higher performance (while preserving accuracy). As I commented, I foresee this requiring a split from the current API that is somewhat inherited from harfbuzz, which means backporting changes from harfbuzz would be harder.

[jackpot51]

A third option is to use harfbuzz directly.

[grovesNL]

Using harfbuzz directly would make it pretty difficult for applications targeting WebAssembly.

[jackpot51]

This is indeed a big issue @grovesNL. There is more talk about this on that rustybuzz issue. My hope is that I can maintain no_std and wasm support indefinitely, regardless of what happens.

[coderedart]

harfbuzz would work fine with wue (wasm32-unknown-emscripten).

But the real problem is wasm_bindgen and wuu (wasm32-unknown-unknown) which is slowly worked on -> rustwasm/wasm-bindgen#3454

[MarcGuiselin]

Hello everyone, I'm new here!

As much as I love rust, I believe having feature-complete (and thus critically more accessible) text shaping is more important.

Having the ability to use harfbuzz with cosmic-text (probably using a feature flag) is IMO the only correct solution moving forward, because as RazrFalcon explains it's simply not sustainable to maintain rustybuzz without any backing. So as time goes on, we'll only see more issues crop up unless someone takes up the mantle.

Rustybuzz should serve as a fallback on wasm targets until rustwasm/wasm-bindgen#3454 is addressed (and any other cross-compilation issues). Additionally, in browser environments it always remains possible to use the browser's own text editing support.

None of this is ideal, but at least provides a workable path forward that leaves plenty of room for improvements in the future.

[grovesNL]

@MarcGuiselin I target both native and WebAssembly and wouldn't want to include harfbuzz (even if it was technically possible to use a common ABI) because of the extra size and complexity of including a C++ toolchain. I also can't use the browser's built-in shaping for WebAssembly.

[DemiMarie]

@MarcGuiselin In certain environments (notably Qubes OS and probably SpectrumOS as well), harfbuzz is not acceptable because of security concerns. I’d like to use COSMIC Text to allow rendering arbitrary text in privilege contexts in Qubes OS, but that is only okay if it remains a purely safe Rust library.

[DemiMarie]

@jackpot51 to elaborate on the security concerns: Qubes OS has users (such as Edward Snowden!) who malicious actors might well be willing to burn zero-day exploits on. A zero-day in Harfbuzz that can be triggered purely through malicious text to be rendered (as opposed to requiring a malicious font) is not something I have been able to exclude. And unlike browsers, there is no sandboxing here: if an attacker can compromise the text renderer used for e.g. notifications, it is Game Over.

[coderedart]

I think the situation has changed a little bit. rustybuzz seems to be accepting (and asking for) patches RazrFalcon/rustybuzz#79 to backport harfbuzz improvements. So, is it still "deprecated"?

Anyway, i get the spirit of wanting pure rust libraries, but i am also worried about the amount of effort it requires (compared to raw c bindings). If the community had the bandwidth to maintain rustybuzz, this issue would have never been created at all. rustybuzz is not a one time thing. It will require continuous and persistent effort to keep up with harfbuzz, and it will need people who are good at both rust AND advanced c++.

I would support just using harfbuzz to ease the maintenance burden. the burden can also be shared with servo team https://github.com/servo/rust-harfbuzz . Or at least feature gate harfbuzz and rustybuzz so that we always have a mature (and easier to maintain) backend for people on desktop and a pure rust backend for people who have different needs.