Page MenuHomePhabricator

Fash issue with digit unicode after emoji unicode.
Closed, ResolvedPublic

Description

Look at "123"/"321" on both sides of "A",
The font "123" on the left of "A" and "321" on the right of "A" is different.

"123" is the emoji font.
"321" is the default font.

"123" is affected by the font cache caused by "가" to the left of ☪.
"321" is affected by "A".

Perhaps this is a natural behavior by efl font cache logic.

However, some emoji fonts have digit index but no glyphs.
In this case, "123" on the left of A is not output. (Because there is no glyph)

In general, when user enter a number,
user's expectation will be the default font rather than the emoji font.
(And if user want emoji font, user can use variation selector.)

What do you think?
Do you have a good idea for this problem?

Below is test code.

#include <Elementary.h>
/*
gcc -o example test.c `pkg-config --cflags --libs elementary`
*/

EAPI_MAIN int
elm_main(int argc EINA_UNUSED, char **argv EINA_UNUSED)
{
   Evas_Object *win, *en;

   elm_policy_set(ELM_POLICY_QUIT, ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);

   win = elm_win_util_standard_add("emoji-example", "emoji-example");
   elm_win_autodel_set(win, EINA_TRUE);

   en = elm_entry_add(win);
   elm_entry_scrollable_set(en, EINA_TRUE);
   evas_object_size_hint_weight_set(en, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
   evas_object_size_hint_align_set(en, EVAS_HINT_FILL, EVAS_HINT_FILL);

   elm_object_text_set(en, "<font_size=25>가&#x262a;123A321<br>"
                                         "가&#x262a;&#xfe0f;123A321<br>"
                                         "가&#x262a;&#xfe0e;123A321<br>");

   evas_object_show(en);

   elm_object_content_set(win, en);
   evas_object_resize(win, 400, 200);
   evas_object_show(win);

   elm_run();

   return 0;
}
ELM_MAIN()
bowonryu created this task.Jan 7 2020, 10:36 PM
bowonryu triaged this task as Showstopper Issues priority.

However, some emoji fonts have digit index but no glyphs.

I think this is not right anyway, why font says he have unicode representation and do not have a glyph ? this will still a problem any way.

But for the reset, EFL glyph logic for efficiency reasons cause unicodes representation So it does not search for it again, And you are right output is not expected by the user.

ali.alzyod added a comment.EditedJan 8 2020, 11:05 PM

@bowonryu I am thinking of treat variation sequence in a special way, where it does not affect font used for the rest of the text.
This will also fix T8542 too.

@bowonryu I think will D11229 fix this issue, but we need to double-check behavior.
Please let me know what do you think?

Hmmm, it seems more work needs to be done.
<font_size=25>가123A321</font_size> will work as expected
<font_size=25>가&#x262a;123A321</font_size> will still have ossues

Thanks for your effort :)

Actually in my environment both work as expected.
Hmmm.. what's the difference in the environment?

Anyway, we have to discuss it again after your work is done.

Hmmm.. what's the difference in the environment?

Fonts Used

Anyway, we have to discuss it again after your work is done.

I hope to find more generic solution for all cases

@bowonryu Please let me know what you think. D11302

ali.alzyod closed this task as Resolved.Apr 19 2020, 1:34 AM