Repository files navigation

rustybuzz is a completeharfbuzz'sshaping algorithm port to Rust.

Matchesharfbuzz v10.1.0.

Because you can addrustybuzz = "*" to your project and it just works.No need for a C++ compiler. No need to configure anything. No need to link to system libraries.

rustybuzz passes nearly all of harfbuzz shaping tests (2221 out of 2252 to be more precise).So it's mostly identical, but there are still some tiny edge-cases whichare not implemented yet or cannot be implemented at all.

• Subsetting removed.
• TrueType parsing is completely handled by thettf-parser.And while the parsing algorithm is very different, it's not better or worse, just different.
• Malformed fonts will cause an error. HarfBuzz uses fallback/dummy shaper in this case.
• No font size property. Shaping is always using UnitsPerEm. You should scale the result manually.
• Most of the TrueType and Unicode handling code was moved into separate crates.
• rustybuzz doesn't provide any integration with external libraries, so no FreeType, CoreText, or Uniscribe/DirectWrite font-loading integration, and no ICU, or GLib Unicode-functions integration, as well as nographite2 library support.
• mort table is not supported, since it's deprecated by Apple.
• No Arabic fallback shaper. This requires the ability to build lookups on the fly. In HarfBuzz (C++) this requires serialization code that is associated with subsetting.
• avar2 as well as other parts of the boring-expansion-spec are not supported yet.

At the moment, performance isn't that great. We're 1.5-2x slower than harfbuzz.

Seebenches/README.md for details.

rustybuzz is not a faithful port.

harfbuzz can roughly be split into 6 parts: shaping, subsetting, TrueType parsing,Unicode routines, custom containers and utilities (harfbuzz doesn't use C++ std)and glue for system/3rd party libraries. In the mean time, rustybuzz contains only shaping.All of the TrueType parsing was moved to thettf-parser.Subsetting was removed. Unicode code was mostly moved to external crates.We don't need custom containers because Rust's std is good enough.And we do not use any non Rust libraries, so no glue code either.

In the end, we still have around 23 KLOC. While harfbuzz is around 80 KLOC.

As mentioned above, rustybuzz has around 23 KLOC. But this is not strictly true,because there are a lot of auto-generated data tables.

You can find the "real" code size using:

tokei --exclude hb/unicode_norm.rs --exclude hb/ot_shaper_vowel_constraints.rs \      --exclude'*_machine.rs' --exclude'*_table.rs' src

Which gives us around 17 KLOC, which is still a lot.

Since the port is finished, there is not much to do other than syncing it witha new harfbuzz releases. However, there is still lots of potential areas of improvement:

• Wider test coverage: Currently, we only test the result of the positioned glyphs in the shaping output.We should add tests so that we can test other parts of the API as well, such as glyph extents and glyph flags.
• Fuzzing against harfbuzz: Whilerustybuzz passes the wholeharfbuzz test suite, this does not mean thatoutput will always be 100% identical toharfbuzz. Given the complexity of the code base, there are bound to beother bugs that just have not been discovered yet. One potential way of addressing this issue could be to create afuzzer that takes random fonts, and shapes them with a random set of Unicode codepoints as well asinput settings. In case of a discovered discrepancy, this test case could then be investigated and once thebug has been identified, added to our custom test suite. On the one hand we could use the Google Fonts fontcollection for this so that the fonts can be added to the repository,but we could also just use MacOS/Windows system fonts and only test them in CI, similarlyto how it's currently done for AAT inharfbuzz.
• Performance:harfbuzz contains tons of optimization structures(accelerators and caches) which have not been included inrustybuzz. As a result of this,performance is much worse in many cases, as mentioned above (although in the grand scheme of thingsrustybuzz is still very performant), but the upside of excluding all those optimizations is thatthe code base is much simpler and straightforward. This makes it a lot easier to backport new changes(which already is a very difficult task). Now that we are back in sync withharfbuzz, we can considerattempting to port some of the major optimization improvements fromharfbuzz, but we should do so carefullyto not make it even harder to keep the code bases in sync.
• Code alignment:rustybuzz tries its best to make the code base look like a 1:1 C++ to Rust translation,which is the case for most parts of the code, but there also are many variations (most notable in AAT) that arisefrom the fact that a lot of the C++ concepts are not straightforward to port. Nevertheless, there probably stillare parts of the code that probably could be made more similar, given that someone puts time into looking into that.

All of this is a lot of work, so contributions are more than welcome.

The library is completely safe.

We do have oneunsafe to cast between two POD structures, which is perfectly safe.But except that, there are nounsafe in this library and in most of its dependencies(excludingbytemuck).

• harfbuzz_rs - bindings to the actual harfbuzz library.As of v2 doesn't expose subsetting and glyph outlining, which harfbuzz supports.
• allsorts - shaper and subsetter.As of v0.6 doesn't support variable fonts andApple Advanced Typography.Relies on some unsafe code.
• swash - Supports variable fonts, text layout and rendering.No subsetting. Relies on some unsafe code. As of v0.1.4 has zero tests.

rustybuzz is licensed under theMIT.

harfbuzz islicensed under theOld MIT