floooh / sokol

minimal cross-platform standalone C headers
https://floooh.github.io/sokol-html5
zlib License
7.04k stars 494 forks source link

Feature: allow using sokol_fontstash with sokol_nuklear #512

Open ghost opened 3 years ago

ghost commented 3 years ago

sokol_nuklear assumes NK_INCLUDE_FONT_BAKING is set due to its usage of nk_font_atlas, which #defines a vendored copy of stb_truetype. by comparison, fontstash requires #including the stb_truetype library. each library individually #defines its own overrides of STBTT_malloc and STBTT_free, further complicating things.

as nuklear allows using an external font baker, I propose a toggleable #define for sokol_nuklear that exposes an api with that functionality, possibly catering specifically to sokol_fontstash for convenience in sokol_glue.

wmerrifield commented 3 years ago

As I wrote most of sokol_nuklear originally I'll take a look at this later on this week :) (Unless anybody else wants to ;) )

floooh commented 3 years ago

Are these actually two separate things?

(1) allow using sokol_fontstash.h and sokol_nuklear.h side by side (e.g. resolve any symbol collisions from stb_truetype.h via STBTT_STATIC: https://github.com/nothings/stb/blob/c9064e317699d2e495f36ba4f9ac037e88ee371a/stb_truetype.h#L98-L99 (which seems very simple)

(2) allow sokol_fontstash.h as font baking solution for sokol_nuklear.h (which seems quite a bit more complicated and a bit "esoteric")?

ghost commented 3 years ago

If they're both first included in the same .c file, STBBT_STATIC won't help. A minor issue perhaps, but doesn't really fit with the ease of use of the rest of the sokol suite, and doesn't remove unnecessary library duplication.

A better solution may be to upstream changes to nuklear to allow bringing your own stb_truetype