Horizontal shift of strings when using XBF fonts

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Horizontal shift of strings when using XBF fonts

    Hi,

    Recently we switched from using fonts in C-file format to using XBF fonts, because we ran out of code memory.
    Since this change we have an issue, that right or center aligned text is sometimes displayed at the wrong horizontal offset.
    This problem occurs when using the GUI_DispStringAt function, but also widgets (like buttons) have this issue sometimes. The weird thing is that most of the time the string is displayed correct, but occasionally it looks like it's shifted to the left. Sometimes it's only a few pixels, other times it's shifted the number of pixels of the string to be displayed. And we don't really have a reproduction scenario, so it's very hard to track.

    I attached an image which shows the problem. The bottom line shows the
    intended situation, the top line shows the problem. The weird thing is that when the string
    is displayed at the wrong offset, next time it draws it at the correct
    offset. Because we don't clear
    the whole area when the string is updated (but only the part where it
    should display the string), we see the string twice on the display.



    When we change the GUI_SetFont to use the C-file instead of the XBF file (without changing any other code), we don't see this problem. So it seems that it has something to do with the XBF fonts.
    Has anyone seen this problem before?
    Thanks in advance.

  • An update from our side. After some further investigation, it seems that this problem only occurs when using extended proportional fonts (with and without AA).
    When using a proportional (non extended) XBF file and changing the GUI_XBF_CreateFont() call to use GUI_XBF_TYPE_PROP, it seems to work fine.
    The thing is that we want to use antialiasing (because it looks much better) and AA is only supported for extented proportional fonts when using XBF files. So it remains a problem for us.

    Is this a known issue or is it maybe already fixed in a newer release? (We use version 5.08 )

  • Hello,

    Unfortunately I am not able to reproduce the problem, but I know that a problem was fixed in emWin V5.10a regarding the XBF functionality. The size of the buffer which was used to get character information was too small. This might possibly solve the problem.

    I understand that it is hard to find the cause of a problem which is not really reproducible, but I would like to give it a try. Could you please provide me with the working and not working font you use and a small example program which shows the erroneous behavior you described? I will then let you know, if I was able to reproduce the problem and if it was already fixed.

    Thank you in advance.

    Best regards,
    Adrian

  • Hi Adrian,

    Thanks for your reply.

    The source below gives you an idea of how we use XBF font files.
    We see this problem when GUI_XBF_TYPE_PROP_AA4_EXT is used (and the corresponding XBF file).

    If we change GUI_XBF_TYPE_PROP_AA4_EXT to GUI_XBF_TYPE_PROP, upload the non-extended XBF file to the SD card and keep the rest of the code as is, we don't see this problem.
    I attached both XBF files (AA + extended and non-extended).

    Maybe it's good to know that often it takes some time before we see this behaviour (even 15 - 30 minutes sometimes) and we only have this problem when the text is center or right aligned.

    C Source Code

    1. typedef struct
    2. {
    3. GUI_FONT Font;
    4. GUI_XBF_DATA XBF_Data;
    5. FS_FILE* pFile;
    6. bool bln_Initialized;
    7. } XBFFontData;
    10. XBFFontData FontData;
    12. int main()
    13. {
    14. FS_Init();
    15. FontData.pFile = FS_FOpen("mmc:1:fonts\\Segoe 32px Normal.xbf", "r");
    17. if (FontData.pFile != NULL)
    18. {
    19. GUI_XBF_CreateFont(&(FontData.Font),
    20. &(FontData.XBF_Data),
    21. GUI_XBF_TYPE_PROP_AA4_EXT,
    22. ReadXBFFontFileC,
    23. (void*) &(FontData));
    25. FontData.bln_Initialized = true;
    27. char c08_DispBuffer[20];
    29. while(1)
    30. {
    31. GUI_SetFont(&FontData.Font);
    32. GUI_SetTextAlign (GUI_TA_RIGHT | GUI_TA_TOP);
    34. uint32 u32_RemainingTime = 0; // GetRemainingTime();
    35. uint32 u32_Minutes = u32_RemainingTime / 60;
    36. uint32 u32_Seconds = u32_RemainingTime % 60;
    37. sprintf (c08_DispBuffer, "%02d:%02d", (int) u32_Minutes, (int) u32_Seconds);
    38. GUI_DispStringAt(c08_DispBuffer, 230 , 3);
    40. GUI_Delay(250);
    41. }
    42. }
    44. return 0;
    45. }
    Display All
    Files

  • I did some further investigation using the debugger and the disassambler. And this is what I found:
    At end of the GUI_GetStringDistX function, the function GUI__GetOverlap gets called. What I figured out from the disassambly is that this function checks if the XDist is smaller than the XPos + XSize of the last character. If not than there is overlap and returns the difference between those two. The XPos, XSize and XDist are in the GUI_CHARINFO_EXT structure and are read in the GUI_XBF__GetCharInfo function. The thing is that not all data is read in that function. What I saw is that XDist and XSize are read, but XPos not. Because the GUI_CHARINFO_EXT is not initialized to zero, the data in XPos is whatever the data on that memory location is at that moment. If this value happens to be zero, everything works fine. But when this value is 0x10 for example, the calculated overlap is wrong, resulting in a wrong string distance. And if this calculated distance is larger than the actual length, the right aligned strings are displayed at the wrong offset because the library thinks the string is longer.

    Is this the issue that is fixed in the 5.10a release?

  • Hello,

    This does not seem to be the issue which was fixed in 5.10a. I will give it another try to reproduce the problem. Please note that the function GUI_XBF_CreateFont() requires to get GUI_XBF_TYPE_PROP_AA4_EXT as third parameter in case an extended font of 4bpp has to be used.

    Best regards,
    Adrian

  • Hi Adrian,

    We use the GUI_XBF_TYPE_PROP_AA4_EXT parameter. But because we now know what's causing the problem, it should be pretty easy to reproduce.
    Just build a copy of the emwin library in which the GUI_XBF__GetCharInfo initializes the XPos variable of the GUI_CHARINFO_EXT struct to for example 0x20. And then try to write a right aligned string to the screen.
    Then you should get the same behaviour as we have, only then all the time because the value of XPos is not random (our case, because not initialized).

  • Hello,

    I am sorry for the delay. I did further investigations on this purpose and found out that updating your emWin library should solve the problem. Please contact your emWin supplier in order to obtain a new emWin software package. It should contain at least emWin V5.10a.

    Best regards,
    Adrian

    The post was edited 1 time, last by SEGGER - Adrian ().

  • Hi Adrian,

    Thanks for your reply. In the meantime we already contacted our supplier and they came to the same conclusion. It's good to know that you and our supplier have come to the same conclusion, so we know for sure that an update of the library will fix our problem.

    Thanks again for the support.

    Kind regards,
    Robbert