Discussion: improving Nuklear's font handling

This is a discussion on how to improve Nuklear's font handling.

Among the specific issues are:

• Excessive memory usage with large (e.g. Chinese) fonts
• Can't handle large fonts
• The non-baking font handling can be improved
• No samples for non-baking handling with GL
• Kerning support

Memory usage / large fonts

Take the case of Chinese fonts for instance. The 'glyph ranges' for Chinese is
a large number, and the baker bakes every codepoint in that range whether or not
the codepoint is used (and certainly, most glyphs will not be used).

What happens is that the rendered font is too big to be used, apparently, since
one gets a black screen instead of the expected text display.

Suggestion:

• Try to load only those glyph ranges which are actually required

This seems fairly simple: keep track of which pages of Unicode data have been
loaded, and load if not present.

I tried to do this, but have run into other issues with Nuklear's font handling.
For instance: the texture needs to exist before the glyph is rendered, but we
don't necessarily have the glyph loaded yet.

• Try to render on-demand for large font sizes. The drawing information is inherent in the font, though using it is not trivial and may take up lots of drawing commands and be slow as well. Still, it should always work.
• Use more than one texture for the font, swapping in and out as required. This might be more practical.

Improving non-baking font handling

In trying to create a user-defined font-handling mechanism that worked with GL, I encountered the problem that the Nuklear font callbacks return the 'userdata' handle, which is fine; but what really should be given is the font used (perhaps in addition to the userdata). That is because in a demand-load case, one may need or want to resize the texture being used. Maybe there's a better way of doing this?

Furthermore: there's no good documentation of what the various fields in the 'nk_user_font_glyph' should be. Examples would be useful.

Kerning support

The callbacks should have some method for providing kerning information. Right now, there's codepoint and next_codepoint, but for kerning one typically would want 'previous_codepoint' (in that run of text). Keeping track of previous codepoint in the callback is not going to give proper results.

Start by reviewing Nuklear's font callbacks and the nk_user_font_glyph fields, including the non-baking GL handling described in the discussion. The issue needs a decided scope before implementation; done would mean an agreed solution for the selected large-font, callback, documentation, or kerning concern.