encoding_rs VS fontdue

Author of ripgrep here.

Maybe, umm, don't depend on auto-detection tools as the ultimeate source of whether something is appropriately licensed or not? encoding_rs is clearly licensed, otherwise I wouldn't have used it in ripgrep: https://github.com/hsivonen/encoding_rs

Take it up with the auto-detection tools. Or at least do your due diligence before claiming ripgrep is using "unlicensed" code.

RE: the N/A in ripgrep dependencies specifically, it's a little clearer on my machine (newer version of cargo-license maybe?). Slightly complicated but still above board https://github.com/hsivonen/encoding_rs#licensing

> Custom License File (1): encoding_rs

Have you tried encoding-rs - not to be confused with rust-encoding you've already tried? This is the library used by Firefox, so I expect it to be quite good.

You might also want to include tests, https://github.com/hsivonen/encoding_rs/tree/master/src/test_data could be used as a reference.

As far as I can see it does not use SIMD for UTF8 validation, only likely/unlikely instrinsics, see https://github.com/hsivonen/encoding_rs/blob/e98a2096ab09c92...

I'd be curious how this compares with the encoding_rs crate (https://github.com/hsivonen/encoding_rs), which also offers UTF-8 validation (among many other things).

That's not the only use of SIMD in the crate (e.g. see https://github.com/hsivonen/encoding_rs/blob/e98a2096ab09c92...), but I haven't looked into exactly where/how it's used further.

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)