More documentation?

I'm not sure what you mean. If people are using Harfbuzz and are happy with it, then that seems fine to me?

For example, I recently started a UI project, and am using Harfbuzz for text shaping. But I chose Harfbuzz only because it was the only real option I was aware of for text shaping, not because I have experience or good opinion of it.

Counter example: For text rendering, I use FreeType, because it renders quality glyphs. I could have used stb_truetype which is smaller and simpler, but that is more intended for quick/easy uses rather than a focus on quality, and I don't want to run into it's limitations.

From that perspective, I'm looking at kb_text_shape with interest, but haven't been able to tell if it targets the same use-cases. Is it like stb_truetype, where it's a quick-n-dirty alternative to Harfbuzz? Or is it perhaps a re-thinking of what a shaping library could be, targeting the same use cases as Harfbuzz but as an alternative approach?

I hope that makes sense. Ultimately I'm curious and want to learn more. 😄

kb_text_shape certainly doesn't target the same use cases as Harfbuzz, since Harfbuzz is trying to be a universal library that works with every broken font under the sun.

kb_text_shape only tries to support proper OpenType fonts. It is much slower at reading the font file, but significantly faster at shaping than Harfbuzz. The API is significantly different and tries to be much more granular and easier to integrate (there are ways to do everything without allocating memory and without callbacks of any kind). For now, kb_text_shape makes no security guarantees of any kind, so, if you do not control which fonts you will be using, I do not recommend using it.

As far as non-shaping features go, kb_text_shape includes segmentation, but does not expose anything having to do with rasterization (no glyph outlines, no pixel scale, etc.)

You are right that I should probably write this up in the README, since this is the second time I've had to type something like this :P

Is this something people would prefer to read in the wiki?

I appreciate the response, it is very informative!

And yes, that seems a great candidate for a wiki page. I had looked to see if you had a wiki before making my original comment.

One annoying problem I ran into: sharing the same font memory buffer between kbts_ReadFontHeader and the FreeType API (through FT_New_Memory_Face) causes memory corruption errors in FreeType due to the fact that kbts_ReadFontHeader stores and modifies the memory buffer, which was not at all obvious from the function name or the documentation.

Hopefully https://github.com/JimmyLefevre/kb/commit/81317554bf9b513dace890e6a9c0fcdaf8c5d564 helps a bit.

I added a section on performance: https://github.com/JimmyLefevre/kb/commit/970609b3f7c6913c3e10929aa816dcf78deda690 As described here https://github.com/JimmyLefevre/kb/issues/21#issuecomment-3067075813