fontdue VS allsorts

The other alternative is to go a level lower and use something like fontdue and then roll my own font rendering pipe, but that seems overkill for what seems like a simple problem.

I agree that no_std is incredible. I really want to see more crates embrace it and encapsulate their no_std logic away from their standard logic. I very often see crates that are like 95% of the way to no_std but then choose to bundle some standard only features without flagging them.

I wrote fontdue [0] (which is very incomplete spec wise) because there just wasn't another font library that was no_std at that time. It felt like the existing libraries were in an arms race for gpu caches and bundling file loading. Like if I wanted to commit to a running on a platform I'd do the sane thing and use harfbuzz or the platform APIs.

[0] https://github.com/mooman219/fontdue

Like tiny-skia? As for font-specific one there are ab-glyph and fontdue.

I work on a SIMD optimized font library [0] and have stumbled into the same situation of hand writing SIMD intrinsics. Some things are just kinda hard to make sure they get optimized correctly, and there is enough difference between the platforms where that matters when fiddling with bits. I also kinda have fun writing SIMD code like this too.

[0]: https://github.com/mooman219/fontdue/blob/master/src/platfor...

The other library that does a similar thing to ab_glyph/rusttype I remember hearing about is fontdue (https://github.com/mooman219/fontdue)

But again you don't need to reinvent text layout from scratch (that's my discussion, BTW) if you use the platform's native text drawing facilities, like DirectWrite on Windows, or CoreText on macOS.

All these layers of Cows create an extremely complex lifetime tree and it's actually not possible to factor out the complex parsing steps into functions because they depend on a lot of stuff. (trying to return an OutlineBuilder from a function would dangling reference about 3 different temporaries, for example. Obtaining the temporaries is part of the parsing step)

machine learning, neural networks, image processing, cryptography (though it is getting better), font shaping/rendering (though it is getting better), CPU/software rendering (though it is getting better)

It can be used for the things you suggest but our driving use case is font parsing. The goal is to use it to generate the font parsing code in Allsorts, which is ultimately used in Prince.

Use allsorts or rustbuzz for text shaping

Loader -> Allsorts

It's something I'd like to improve on in future -- are there any pure-Rust libraries you'd recommend for shaping? Allsorts looks quite promising.