Crates.io | harfruzz |
lib.rs | harfruzz |
version | |
source | src |
created_at | 2025-05-05 02:03:22.128054+00 |
updated_at | 2025-05-07 17:21:10.213515+00 |
description | A complete harfbuzz shaping algorithm port to Rust. |
homepage | |
repository | https://github.com/harfbuzz/harfruzz |
max_upload_size | |
id | 1660060 |
Cargo.toml error: | TOML parse error at line 22, column 1 | 22 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
harfruzz
is a fork of rustybuzz
to explore porting from ttf-parser
to
read-fonts
to avoid shipping (and maintaining)
multiple implementations of core font parsing for skrifa
consumers.
Further context in https://github.com/googlefonts/fontations/issues/956.
rustybuzz
is a complete harfbuzz's
shaping algorithm port to Rust.
Matches harfbuzz
v9.0.0.
https://github.com/googlefonts/oxidize outlines Google Fonts motivations to try to migrate font production and consumption to Rust.
The following conformance issues need to be fixed:
avar2
as well as other parts of the boring-expansion-spec are not supported yet.mort
table is not supported, since it's deprecated by Apple.graphite
library support.At the moment, performance isn't that great. We're 1.5-2x slower than harfbuzz.
See benches/README.md for details.
harfruzz is not a faithful port.
harfbuzz (C++ edition) can roughly be split into 6 parts:
hb-subset
) moves to a standalone crate, klipparead-fonts
fontations
where appropriate (e.g. int set)You can find the "real" code size (eliminating generated code) using:
tokei --exclude hb/unicode_norm.rs --exclude hb/ot_shaper_vowel_constraints.rs \
--exclude '*_machine.rs' --exclude '*_table.rs' src
Since the port is finished, there is not much to do other than syncing it with a new harfbuzz releases. However, there is still lots of potential areas of improvement:
rustybuzz
passes the whole harfbuzz
test suite, this does not mean that
output will always be 100% identical to harfbuzz
. Given the complexity of the code base, there are bound to be
other bugs that just have not been discovered yet. One potential way of addressing this issue could be to create a
fuzzer that takes random fonts, and shapes them with a random set of Unicode codepoints as well as
input settings. In case of a discovered discrepancy, this test case could then be investigated and once the
bug has been identified, added to our custom test suite. On the one hand we could use the Google Fonts font
collection 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, similarly
to how it's currently done for AAT in harfbuzz
.harfbuzz
contains tons of optimization structures
(accelerators and caches) which have not been included in rustybuzz
. As a result of this,
performance is much worse in many cases, as mentioned above (although in the grand scheme of things
rustybuzz
is still very performant), but the upside of excluding all those optimizations is that
the 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 with harfbuzz
, we can consider
attempting to port some of the major optimization improvements from harfbuzz
, but we should do so carefully
to not make it even harder to keep the code bases in sync.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 arise
from the fact that a lot of the C++ concepts are not straightforward to port. Nevertheless, there probably still
are 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 one unsafe
to cast between two POD structures, which is perfectly safe.
But except that, there are no unsafe
in this library and in most of its dependencies
(excluding bytemuck
).
harfruzz
is licensed under the MIT license.
harfbuzz
is licensed under the Old MIT