-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The width of the text obtained using u8g2_GetStrWidth is very strange #2446
Comments
We can discuss here, how the width gets calculated, but in general the value has been defined by the font author. |
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. |
Font sourcehttps://www.unifoundry.com/pub/unifont/unifont-15.1.05/font-builds/unifont-15.1.05.bdf.gz Font conversiontest.map:
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"; Reproduction codeint 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:
|
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. |
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. |
Thank you for your reply. I will try it out. |
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.The text was updated successfully, but these errors were encountered: