Request for ImFontBaked::FindGlyphByGlyphId #9559

New issue

Closed

opened 2026-09-26 09:57:40 +00:00 by rodrigorc · 3 comments

rodrigorc commented

2026-09-26 09:57:40 +00:00

(Migrated from github.com)

Version/Branch of Dear ImGui:

Version v1.92.9b

Back-ends:

n/a

Compiler, OS:

all

Full config/build information:

No response

Details:

I'm writing a program that uses ImGui as the main UI, and then reuses the ImGui font atlas to render text in some canvas. It works great, but now I'm doing some low level stuff with the fonts, and I need to access some glyphs in my TTF that don't have a char mapped (think of alternative shapes, custom ligatures and the like).

For normal characters I just call ImFontBaked::FindGlyph(ImWchar c), but for these weird glyphs I would need a ImFontBaked::FindGlyphByGlyphId(uint32_t glyph_id) and that it bypass the char->glyph_id mapping.

Naturally I can use AddCustomRect() but that forces me to do the render of the font myself, and the code for that is already there inside ImGui...

I reckon this is a niche need, and that it may break some assumptions in the code (everything is indexed by codepoint). But I was thinking that if instead one function ImFontLoader::FontBakedLoadGlyph(ImWchar codepoint, ...) we had two: uint32_t ImFontLoader::FontSrcMapCodepointToGlyphId(ImWchar codepoint) and then ImFontLoader::FontBakedLoadGlyph(uint32_t glyphId, ...). Then I could just subclass the standard ImFontLoader, and add my desired glyph_ids to the private unicode block....

### Version/Branch of Dear ImGui: Version v1.92.9b ### Back-ends: n/a ### Compiler, OS: all ### Full config/build information: _No response_ ### Details: I'm writing a program that uses ImGui as the main UI, and then reuses the ImGui font atlas to render text in some canvas. It works great, but now I'm doing some low level stuff with the fonts, and I need to access some glyphs in my TTF that don't have a char mapped (think of alternative shapes, custom ligatures and the like). For normal characters I just call `ImFontBaked::FindGlyph(ImWchar c)`, but for these weird glyphs I would need a `ImFontBaked::FindGlyphByGlyphId(uint32_t glyph_id)` and that it bypass the char->glyph_id mapping. Naturally I can use `AddCustomRect()` but that forces me to do the render of the font myself, and the code for that is already there inside ImGui... I reckon this is a niche need, and that it may break some assumptions in the code (everything is indexed by codepoint). But I was thinking that if instead one function `ImFontLoader::FontBakedLoadGlyph(ImWchar codepoint, ...)` we had two: `uint32_t ImFontLoader::FontSrcMapCodepointToGlyphId(ImWchar codepoint)` and then `ImFontLoader::FontBakedLoadGlyph(uint32_t glyphId, ...)`. Then I could just _subclass_ the standard ImFontLoader, and add my desired glyph_ids to the private unicode block....

ocornut commented

2026-09-28 12:20:36 +00:00

(Migrated from github.com)

What do you refer to as glyph_id, is the glyph index in a given font?

It is this?
stb_truetype:

    ImGui_ImplStbTrueType_FontSrcData* bd_font_data = (ImGui_ImplStbTrueType_FontSrcData*)src->FontLoaderData;
    IM_ASSERT(bd_font_data);
    int glyph_index = stbtt_FindGlyphIndex(&bd_font_data->FontInfo, (int)codepoint);
    if (glyph_index == 0)
        return false;

FreeType:

    ImGui_ImplFreeType_FontSrcData* bd_font_data = (ImGui_ImplFreeType_FontSrcData*)src->FontLoaderData;
    uint32_t glyph_index = FT_Get_Char_Index(bd_font_data->FtFace, codepoint);
    if (glyph_index == 0)
        return false;

Are they glyphs that are not accessible via a codepoint?
I recall https://github.com/ocornut/imgui/issues/5647#issuecomment-1238127411 mentioned this.

What do you refer to as glyph_id, is the glyph index in a given font? It is this? stb_truetype: ``` ImGui_ImplStbTrueType_FontSrcData* bd_font_data = (ImGui_ImplStbTrueType_FontSrcData*)src->FontLoaderData; IM_ASSERT(bd_font_data); int glyph_index = stbtt_FindGlyphIndex(&bd_font_data->FontInfo, (int)codepoint); if (glyph_index == 0) return false; ``` FreeType: ```cpp ImGui_ImplFreeType_FontSrcData* bd_font_data = (ImGui_ImplFreeType_FontSrcData*)src->FontLoaderData; uint32_t glyph_index = FT_Get_Char_Index(bd_font_data->FtFace, codepoint); if (glyph_index == 0) return false; ``` Are they glyphs that are not accessible via a codepoint? I recall https://github.com/ocornut/imgui/issues/5647#issuecomment-1238127411 mentioned this.

rodrigorc commented

2026-09-29 17:41:21 +00:00

(Migrated from github.com)

It is this?

Yes, here it is called glyph_index, just the index in the glyph table. 0 is reserved for ".notdef".

Are they glyphs that are not accessible via a codepoint?

Indeed. TTF fonts store glyphs in an array, the glyph id is just the index in that array. Then there is the cmap table that maps character codes (usually Unicode codepoints) to glyph_index. But that is the short story, TTF fonts support also:

Ligatures. Grammatical ligatures such as æ have the own codepoint, and popular ones such as fi, fl, ffi do have one too. But the TTF author can define whatever ligatures they want. For example my Palatino version has Qu, Th, ct, ft.
Variation. Your linked comment is right, there are many tables of character variations (I don't claim to even understand most of them...) Many have their own Unicode codepoint, but many more do not. Style, size, position, language, age... My favorites are small caps and old-style numbers, none of those have Unicode points!
Composition. Sometimes a glyph is used as a part of several other glyphs, and is not intended used on its own. No cmap entry for this one.
Private use. Yes, there is the private Unicode block, but some fonts hide fancy glyphs without assigning any codepoint to them.
Math. Some fonts have a lot of math stuff.

We can see the unmapped glyphs of a font using FontForge and setting the option "View / Label glyph by / Unicode". The unmapped glyphs show a "?". For example, my Palatino font has these:

> It is this? Yes, here it is called `glyph_index`, just the index in the glyph table. 0 is reserved for ".notdef". > Are they glyphs that are not accessible via a codepoint? Indeed. TTF fonts store glyphs in an array, the glyph id is just the index in that array. Then there is the `cmap` table that maps character codes (usually Unicode codepoints) to glyph_index. But that is the short story, TTF fonts support also: * Ligatures. Grammatical ligatures such as `æ` have the own codepoint, and popular ones such as `fi`, `fl`, `ffi` do have one too. But the TTF author can define whatever ligatures they want. For example my Palatino version has `Qu`, `Th`, `ct`, `ft`. * Variation. Your linked comment is right, there are many tables of character variations (I don't claim to even understand most of them...) Many have their own Unicode codepoint, but many more do not. Style, size, position, language, age... My favorites are small caps and old-style numbers, none of those have Unicode points! * Composition. Sometimes a glyph is used as a part of several other glyphs, and is not intended used on its own. No cmap entry for this one. * Private use. Yes, there is the private Unicode block, but some fonts hide fancy glyphs without assigning any codepoint to them. * Math. Some fonts have _a lot_ of math stuff. We can see the unmapped glyphs of a font using FontForge and setting the option "View / Label glyph by / Unicode". The unmapped glyphs show a "?". For example, my Palatino font has these: <img width="3703" height="1104" alt="Image" src="https://github.com/user-attachments/assets/3d5daa5c-8656-4f1c-bf71-fa80b3d23f07" />

👍 1

ocornut commented

2026-09-29 18:19:35 +00:00

(Migrated from github.com)

Understood. I think I can make this change.