The library poorly renders the unsupported text and then crashes.

This text is "𝙸 m̵̐̈́ẻ̷̋a̴͒̋n̴̓̚ 𝕴 𝑪𝒂𝒏 𝓓𝓸 𝕋𝕙𝕚𝕤"

(Again, I will solve this issue, this is just here for organization's sake)

The texture for the fonts aren't rendering on windows, there are only rectangles being rendered.

Maybe this issue is related to how much memory the atlas is using?

Note, this issue is only here for the sake of organization, documentation and not losing track of issues.
I plan on fixing this issue.

Hello, Im using RFont with GLFW and Glad (openGL 3.3) when I render my Font the Background gets set to black, and everything I render afterwards (like draw cycles, rectangles and so on) is not beeing displayed. If I place the draw text before my other render stuff, only the text with black background is displayed in the window ... and if i do my rendering first and then the text... its again just displayed the text on black background.

Is there a thing needs to done before? For example hook in the GLFW Context or the Glad RFont context pointer into Glad (like this GLFW load user pointer)?

Edit: Im doing Bindings right now, and not expericing it in a C example... so it should be a binding error i will look into that

If I understand correctly there are a number of internal offsets in the code that don't validate against the overall buffer size, so there isn't any robustness to unsafe data (which is why stb_truetype.h warns users about that in their comments.) I would imagine RFont has the same limitations, since it uses stb_truetype code? If so, I was wondering if there might be any plans to make RFont more robust by adding the offset validations?

Text using the Helvetica font in RFont usually looks fine, however in some instances some letters have very odd spacing that makes them look very awkward compared to the rest of the string. In the example below you can see that happening with the letter 'v', where it's off by a few pixels:

Using LibreOffice Writer, this is how I expect the text to look more or less:

And it isn't only with 'v'. "Button" suffers from the same issue, alongside many other random combinations of words.