Imgui: Error in text width calculation?

Created on 23 Aug 2016  ·  3Comments  ·  Source: ocornut/imgui

I assume that text rendered as a whole (i.e. by calling ImGui::TextUnformatted("text")) and symbol by symbol like this:

ImGui::TextUnformatted("t");
ImGui::SameLine(0, 0);
ImGui::TextUnformatted("e");
ImGui::SameLine(0, 0);
...

should give the same result. However, ImGui::CalcTextSize does some substraction that does not seem to be right.
This demonstration is copied from opengl_example. It contains two functions to output text: as a whole and symbol by symbol. They give different results. First string is rendered as a whole and second string is rencder symbol by symbol.
screenshot from 2016-08-23 17-55-22

However, if we change ImGui::CalcTextSize like this:

ImVec2 ImGui::CalcTextSize(const char* text, const char* text_end, bool hide_text_after_double_hash, float wrap_width)
{
    ImGuiContext& g = *GImGui;

    const char* text_display_end;
    if (hide_text_after_double_hash)
        text_display_end = FindRenderedTextEnd(text, text_end);      // Hide anything after a '##' string
    else
        text_display_end = text_end;

    ImFont* font = g.Font;
    const float font_size = g.FontSize;
    if (text == text_display_end)
        return ImVec2(0.0f, font_size);
    ImVec2 text_size = font->CalcTextSizeA(font_size, FLT_MAX, wrap_width, text, text_display_end, NULL);

    // Cancel out character spacing for the last character of a line (it is baked into glyph->XAdvance field)
//    const float font_scale = font_size / font->FontSize;
//    const float character_spacing_x = 1.0f * font_scale;
//    if (text_size.x > 0.0f)
//        text_size.x -= character_spacing_x;
    text_size.x = (float)(int)(text_size.x + 0.95f);

    return text_size;
}

two functions render the same result:
screenshot from 2016-08-23 17-57-08

Tested on Ubuntu 16.04 64 bit.

bug fontext

Most helpful comment

Hello,

You'll find it amusing but I have finally fixed this! Better late than never.
While looking at font scaling today I have noticed that although the comment made sense (and complicated things), the assumption it made about extra spacing being baked inside the AdvanceX value was actually wrong, at least it is now.

I'll removed the subtraction now.

Thanks and sorry for taking so long to tackle this!

Omar

All 3 comments

I believe this is worth a flag in CalcTextSize, because both behaviors are correct, just doing different things (calculate size of a text fragment within a string vs. calculate size of a displayed text string)

If I understand you correctly fixed-width font is not rendered like

symbol, symbol, symbol

but contains spacing between them

symbol spacing symbol spacing symbol

In which case rendering string as a whole and symbol by symbol would cause different results. If this is true, how is developer supposed to pad strings when working with fixed-width font? Copying padding and rendered string into a buffer is not an option for me (would make rendering functions way too complicated).

Hello,

You'll find it amusing but I have finally fixed this! Better late than never.
While looking at font scaling today I have noticed that although the comment made sense (and complicated things), the assumption it made about extra spacing being baked inside the AdvanceX value was actually wrong, at least it is now.

I'll removed the subtraction now.

Thanks and sorry for taking so long to tackle this!

Omar

Was this page helpful?
0 / 5 - 0 ratings

Related issues

spaderthomas picture spaderthomas  ·  3Comments

CesaragsUC picture CesaragsUC  ·  3Comments

ghost picture ghost  ·  3Comments

dowit picture dowit  ·  3Comments

bogdaNNNN1 picture bogdaNNNN1  ·  3Comments