Provide a Harfbuzz alternative

[DemiMarie]

Harfbuzz is widely used and has had security problems in the past. It would be nice to provide an API that can be used to replace Harfbuzz in the applications Harfbuzz is used in.

[wezm]

Are you imagining that Allsorts would expose a C API that was Harfbuzz compatible so that it was a drop in replacement?

[DemiMarie]

That would be ideal. That said, an API that can be used in e.g. Slint would also be great.

[alerque]

If you want a drop in replacement with memory safety you should probably look into the attempts to port Harfbuzz directly to Rust rather than a completely alternative shaping implementation. I know there is substantial history there however and while I'm not an expert on the matter I suspect there are good reasons none of the attempts have gotten to full parity.

• https://github.com/RazrFalcon/rustybuzz
• https://github.com/manuel-rhdt/harfbuzz_rs
• https://github.com/servo/rust-harfbuzz

[rice7th]

I think that a C api would be useful nonetheless. I am not talking about a drop in replacement for Harfbuzz, but more as an alternative to it for C projects too, since atm Harfbuzz is the only shaping library for C and C++, and it is huge.

[alerque]

@rice7th Harfbuzz is "huge" (it isn't really that big, but whatever metric you want to use is fine) because the task of shaping text is huge. Probably much more complex than you give it credit for, and if you think using some "lighter" shaping engine is a good idea just for the sake of size you should be aware the trade off you are making is a lack of shaping features needed for some languages and situations. This is nothing against allsorts as it is and I'm sure it has merits. This is just a word of caution that text shaping is a much harder problem than most people think of it as and most shaping libraries are only partial implementations of the problem space (Unicode & languages).

[DemiMarie]

@alerque For me, the main problems I have with HarfBuzz are:

• Very large C++ attack surface.
• No way to impose system-wide policies that protect against Zalgo text.

As a result, Qubes OS limits text to ASCII-only in certain situations, and imposes a character allowlist in others. That allowlist only includes certain languages and does not include combining characters at all. A memory safe shaping engine that could be configured (via e.g. a file in /etc) to limit the height of a glyph would allow removing both of these restrictions.

[rice7th]

@alerque sure, but not everyone needs a shaping engine capable of everything if they're only going to support a few common alphabets (like latin & cyrillic) with only a few ligatures. Harfbuzz for most projects is really overkill imo