Closed xray-bit closed 1 week ago
We can discuss here, how the width gets calculated, but in general the value has been defined by the font author. In fact there might be a bug in the BDF sources. You might also consider to use monospaced option while creating the binary code to get a more predictable width. For further discussion mit would be good to see the overview picture, which is generated by bdfconv including the "-a" option.
I am using CJK characters, and if I use the monospaced option, the width of ASCII characters will become the same as CJK characters (twice the original width)
Still it would be great to have an example of a wrong calculated width.
https://www.unifoundry.com/pub/unifont/unifont-15.1.05/font-builds/unifont-15.1.05.bdf.gz
test.map:
32-126
cmd:
bdfconv.exe -v -b 0 -f 1 -M .\test.map -n u8g2_font_unifont_16_test -o u8g2_font_unifont_16_test.c -d .\unifont-15.1.05.bdf .\unifont-15.1.05.bdf
result of the font:
/*
Fontname: -gnu-Unifont-Medium-R-Normal-Sans-16-160-75-75-c-80-iso10646-1
Copyright: Copyright (C) 1998-2024 Roman Czyborra, Paul Hardy, Qianqian Fang, Andrew Miller, Johnnie Weaver, David Corbett, Nils Moskopp, Rebecca Bettencourt, Ho-Seok Ee, et al. License: SIL Open Font License version 1.1 and GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html> with the GNU Font Embedding Exception.
Glyphs: 95/57084
BBX Build Mode: 0
*/
const uint8_t u8g2_font_unifont_16_test[1191] U8G2_FONT_SECTION("u8g2_font_unifont_16_test") =
"_\0\3\2\3\4\4\5\5\10\20\0\376\12\376\13\377\1\212\3\24\4\212 \5\0\364\30!\7Q\206"
"\30\207D\42\10%\305\30\231[\0#\17\326\204X=\15C\22\265\14C\324\23\0$\21\327\204x\341"
"\240D\221\24\316c$U\6\61\3%\24\327\204\70\232\224\224\222HI\343\64\221\222()i\12\0&"
"\21\327\204X[)\253\204b\22i\211\230d\322\24'\7!\306\30C\0(\14\343}XI\224D\275"
"EY\0)\14c}\30Y\224E\275DI\4*\15\277\214x\245J\333\226\64\325\62\0+\13\277\214"
"xqm\30\262\270\6,\10\242u\30J\242\0-\7\14\245\30C\0.\7\222\205\30C\0/\13\326"
"\204\270\305j\230\206\325\24\60\21\326\204XZ\224\204\332\224(\321&&Q&\1\61\13U\205X\231\224"
"\204}\32\4\62\16\326\204\70C\22\212i\246\205\325t\30\63\20\326\204\70C\22\212i\64\247\242\230\14"
"\11\0\64\20\326\204\230\241\226D\225,\311\222aL+\0\65\16\326\204\30\207\264:\310i*&C\2"
"\66\16\326\204XS\230\246\203\22:&C\2\67\13\326\204\30\327bZL\233\0\70\17\326\204\70C\22"
"\32\223!\11\35\223!\1\71\16\326\204\70C\22\32\223Am\214&\0:\10\272\215\30C<\4;\12"
"\312}\30C\254$\12\0<\10M\205\230Y\327\16=\10\256\224\30w\342\60>\11\315\204\30i\267\216"
"\0\77\16\326\204\70C\22\212iX\315\301\64\2@\22\326\204XS&%J\262DJ\244D\322\22\17"
"\1A\15\326\204XZ\324\22\212\303 :\6B\16\326\204\30\203\22\32\207%t\34\26\0C\15\326\204"
"\70C\22Z;\212\311\220\0D\15\326\204\30C\224%\241\337\222!\2E\14\326\204\30\207\264:(i"
"\353\60F\14\326\204\30\207\264:(iW\0G\16\326\204\70C\22ZKChS\226\0H\13\326\204"
"\30\241\343\60\210\36\3I\12U\205\30\203\24\366\323 J\15\327\204X\203\30\367\224EY\266\1K\21"
"\326\204\30\241\226D\225L\24\223,\252%a\0L\11\326\204\30i\177\35\6M\14\326\204\30\241\70\15"
"\321\342\321\61N\20\326\204\30\341\266)\221\22I\211\224h\307\0O\14\326\204\70C\22\372c\62$\0"
"P\14\326\204\30\203\22\32\207%\355\12Q\26\337|\70C\24&a\22&a\22&a\222(\211$\15"
"\71 R\20\326\204\30\203\22\32\207%\252%Y\22\212\1S\15\326\204\70C\22\232\35\305dH\0T"
"\12\327\204\30\207,\356o\0U\12\326\204\30\241\177L\206\4V\21\327\204\30\251\65\311\242,\312*a"
"\222\306\31\0W\14\326\204\30\241\27\227i\210F\61X\17\326\204\30\241\230Dm\242\26\265\204b\0Y"
"\16\327\204\30\251\232dQVI\343n\0Z\12\326\204\30\327b\257\351\60[\11c~\30C\324\77\15"
"\134\13\326\204\30i\134\215\323\270\32]\11\343|\30S\377\64\4^\11\236\314XZ\224\204\1_\7\217"
"|\30\207\0`\7\33\325\30Y\1a\15\306\204\70C\22\246\311\60\332\224%b\15\336\204\30i\313\242"
"\211\216\233\262\0c\14\306\204\70C\22\252\35\223!\1d\14\336\204\270-\213\66zS\226\0e\16\306"
"\204\70C\22\212\303\240\26\223!\1f\14\335\204xRX\32\244\260'\0g\23\336t\270\311\242%Y"
"\222E[:$\241\230\14\11\0h\13\336\204\30i\313\242\211>\6i\13]\205Xa\216\210}\32\4"
"j\14\355t\230uD\354\243\24I\0k\20\336\204\30i[\22U\62\61\311\242Z\22\6l\11]\205"
"\70b\377\64\10m\21\307\204\30\213\22ER$ER$ER$\25n\12\306\204\30\311\242\211>\6"
"o\14\306\204\70C\22\372\230\14\11\0p\16\326t\30\311\242\211\216\233\262\244)\0q\14\326t\70\213"
"\66zS\226\264\0r\13\306\204\30\311\242\211jW\0s\14\306\204\70C\22\312\216\311\220\0t\13\325"
"\204Xai\220\302\256\2u\11\306\204\30\241\337\224%v\14\306\204\30\241\61\211z\23%\0w\21\307"
"\204\30\251\24I\221\24I\221\24I\25\13\0x\16\306\204\30\241\230D\231\250EI(\6y\15\326t"
"\30\241\307$\262\244\225!\1z\11\306\204\30\327\260\327a{\16luXJ\26fQ\261\26e\241\0"
"|\7qv\30\37\4}\16lu\30b\26ea\251\26f\211\4~\12\237\304\70\232\24i\12\0\0"
"\0\0\4\377\377\0";
int reproduct(u8g2_t *u8g2)
{
u8g2_Setup_sh1107_seeed_128x128_f(u8g2, U8G2_R3, u8x8_msg_callback, u8x8_msg_callback);
u8g2_InitDisplay(u8g2);
u8g2_SetPowerSave(u8g2, 0);
u8g2_ClearDisplay(u8g2);
u8g2_SetContrast(u8g2, 128);
u8g2_SetFont(u8g2, u8g2_font_unifont_16_test);
u8g2_SetFontPosBaseline(u8g2);
printf("width=%d of ' '\n", u8g2_GetStrWidth(u8g2, " "));
printf("width=%d of '1'\n", u8g2_GetStrWidth(u8g2, "1"));
printf("width=%d of '12'\n", u8g2_GetStrWidth(u8g2, "12"));
printf("width=%d of '22'\n", u8g2_GetStrWidth(u8g2, "22"));
printf("width=%d of ' 1'\n", u8g2_GetStrWidth(u8g2, " 1"));
printf("width=%d of ' 12'\n", u8g2_GetStrWidth(u8g2, " 12"));
printf("width=%d of ' 22'\n", u8g2_GetStrWidth(u8g2, " 22"));
return 0;
}
output:
width=8 of ' '
width=9 of '1'
width=17 of '12'
width=16 of '22'
width=15 of ' 1'
width=23 of ' 12'
width=23 of ' 22'
still the output looks ok to me. what exactly is your cooncern?
I counted the pixels on the screen, and the actual width of each ASCII character is 8. However, after combining different characters into a string, the width obtained using u8g2_GetStrWidth may not be a multiple of 8.
In some scenarios, I need to calculate the length of the string to determine where to start drawing characters. I expect the width of each ASCII character to be 8, but based on the above results, the calculated length of the string "12" is 17. If drawn right aligned (screen width minus string width), it will devour the pixels of the previous column.
Where could the problem be? Is this an issue with the BDF file, 'bdfconv' tool, or u8g2_GetStrWidth?
In such a case you need to use "-b 2" or "-b 3" with "bdfconv" to force a monospaced font.
I am using CJK characters, and if I use the monospaced option, the width of ASCII characters will become the same as CJK characters (twice the original width)
Can I first convert ASCII characters using the monospace option with a width of 8, then convert CJK characters using the monospace option with a width of 16, and finally merge the two arrays?
If possible, how should I merge these two arrays?
I checked this document: https://github.com/olikraus/u8g2/wiki/u8g2fontformat and modified the Font Header offset 0 and offset 21+22, but it was not successful.
Merging after bdfconv is not possible, but it should be possible to modify the BBX statement in the .bdf file for each glyph. I mean instead of using the monospace options of bdfconv, you could instead modify BBX for each glyph.
Thank you for your reply. I will try it out. I'm going to close this issue for now until I run into a new problem.
code
output
The widths of '12' and '22' are different, but when I add a space in front, the width is the same.
I used a custom font from Unifont. I used the program in
u8g2/tools/font/bdfconv
for conversion.