Thank you. The link to BRT_AN_042.zip does not work unfortunately.
Yes it clearly is a issue with the fonts width table, having the widths in the wrong locations.
Rudolph and me follow the standard FTDI API, and we do not handle the width of individual characters, the display does it using the information in the RAW file.
Therefore Rudolph's code can't be blamed anyway.
Looking a bit further,I found this:
In SourceCodePro-Regular.ttf_40_L4.rawh, the below line exactly explains the problem:
/* Widths */
0,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
The list is actually shifted to much to the front, using the index as in the characters file. The display expect the index conform the ASCII values.
This works fine (modified):
/* Widths */
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,24,
After editing the raw file with a hex-editor and fixing the wrong font-widths, it works!
I changed the values inside the red box from 0x00 to the correct width 0x18 (mono-space font here).
Perhaps the font convert utility can be corrected?
In the mean time I will create my own font convert utility (with GUI).