Some custom Unicode characters can not be displayed in dev-7

Bug (archived)
1

Description

Hi,everyone.
I want to display custom Unicode characters in dev-7.@embeddedthelped me to solve the problem,but there still seems to be something wrong.
Some custom Unicode characters can already be displayed, but some characters cannot be displayed normally. Such as "测试√℃●" only displayed "试" .I tried to change several fonts, but the problem still exists.I think it’s a bug.

What MCU/Processor/Board and compiler are you using?

  • eclipse

What do you want to achieve?

  • Display Unicode and Chinese in dev7

What have you tried so far?

  • I tried to display characters(“测试√℃●” ) in the built-in library directly in Unicode.Only displayed "试" .
  • I try to display a character(example:测unicode:\u6D4B) in the built-in library directly with hex value.But it doesn’t work.
    Size: 20
    Bpp: 4bit-per-pixel
    Symbols: 测试abcd℃●√×
    Enable font compression: no
    Horizontal subpixel hinting: no

I don’t know why some Unicode characters are not displayed correctly.I think it’s a bug.

Code to reproduce

main.c (6.6 KB)
my_font_CH.c (9.5 KB)

  • This is my code in main.
  	static lv_style_t style1;
  	static lv_style_t style2;
  	lv_style_init(&style1);
  	lv_style_init(&style2);

  	LV_FONT_DECLARE(my_font_CH);

  	lv_obj_t * label1 = lv_label_create(lv_scr_act(), NULL);
  	lv_obj_t * label2 = lv_label_create(lv_scr_act(), NULL);
  	lv_obj_add_style(label1, LV_OBJ_PART_MAIN, &style1);
  	lv_obj_add_style(label2, LV_OBJ_PART_MAIN, &style2);
  	lv_style_set_text_font(&style1, LV_STATE_DEFAULT, &my_font_CH);
  	lv_style_set_text_font(&style2, LV_STATE_DEFAULT, &my_font_CH);
  	lv_obj_set_style_local_text_color(label1, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_COLOR_RED);
  	lv_obj_set_style_local_text_color(label2, LV_OBJ_PART_MAIN, LV_STATE_DEFAULT, LV_COLOR_ORANGE);
  	lv_label_set_text(label1, "测试√℃●");
  	char * xx="\u6D4B 试测测测测 试da√测试b℃●√c\uF00C";
  	lv_label_set_text(label2, xx);
  	/* Position the main label */
  	lv_obj_align(label1, NULL, LV_ALIGN_CENTER, 0, 0);
  	lv_obj_align(label2, NULL, LV_ALIGN_CENTER, 0, 12);
  • This is file my_font_CH.c.
#include "lvgl/lvgl.h"

    /* U+6D4B "测" */
    0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5, 0x50,
    0x20, 0x31, 0x1, 0xd0, 0x0, 0xd3, 0xd6, 0xd6,
    0x11, 0xd0, 0x0, 0x13, 0xc7, 0xd1, 0xb2, 0xd0,
    0x3b, 0x15, 0xcb, 0xc1, 0xb1, 0xd0, 0x9, 0x71,
    0xcb, 0xc1, 0xb1, 0xd0, 0x0, 0x70, 0xcb, 0xc1,
    0xb1, 0xd0, 0x1, 0x70, 0xcb, 0xc1, 0xb1, 0xd0,
    0x2d, 0x50, 0x9c, 0x80, 0xa1, 0xd0, 0x9, 0x40,
    0x47, 0xd4, 0x1, 0xd0, 0xc, 0x51, 0x80, 0x8d,
    0x57, 0xd0, 0x9, 0x76, 0x0, 0x3, 0xd, 0x60,
    0x0, 0x0, 0x0, 0x0, 0x0, 0x0,

    /* U+8BD5 "试" */
    0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x2, 0xa2,
    0x0, 0xc, 0x77, 0x0, 0x0, 0x89, 0x0, 0xb,
    0x3a, 0x30, 0x0, 0x23, 0x55, 0x5c, 0x75, 0xc3,
    0x23, 0xa2, 0x0, 0x9, 0x50, 0x0, 0x12, 0xe2,
    0x67, 0xbd, 0x70, 0x0, 0x0, 0xe1, 0xd, 0x15,
    0xa0, 0x0, 0x0, 0xe1, 0xd, 0x12, 0xd0, 0x0,
    0x0, 0xe4, 0x3d, 0x34, 0xe3, 0x14, 0x0, 0xf9,
    0x8e, 0x81, 0x7c, 0x62, 0x2, 0xd0, 0x81, 0x0,
    0xd, 0xf1, 0x0, 0x10, 0x0, 0x0, 0x2, 0xc4
};

Screenshot and/or video

If possible, add screenshots and/or videos about the current state.

1
1.jpg734×356 128 KB

2

I tried to exchange the order of two Unicode characters in glyph_dsc[]
before:测试
after:试测
the character 测 is displayed.

    //{.bitmap_index = 1121, .adv_w = 480, .box_w = 25, .box_h = 27, .ofs_x = 2, .ofs_y = -3},//测
    {.bitmap_index = 1459, .adv_w = 480, .box_w = 28, .box_h = 27, .ofs_x = 1, .ofs_y = -3},//试
    {.bitmap_index = 1121, .adv_w = 480, .box_w = 25, .box_h = 27, .ofs_x = 2, .ofs_y = -3}//测

The Unicode of “试” is \u8BD5,but in unicode_list_0[] the value is 0x8afe.I don’t know why these two values are different.I think the problem may be in the index section.

static const uint16_t unicode_list_0[] = {
    0x0, 0x202c, 0x2143, 0x24f8, 0x6c74, 0x8afe
};
4

I compared the previous version and found that it was the problem of the define LV_USE_ARABIC_PERSIAN_CHARS ；Just define it as 0

2 Likes
5

Thank you very much :grinning:. Now it can be shown that it is really caused by this switch.1