update font processing to handle variation sequences unicodes to select proper glypg in respect to variation seqences
Details
Details
#define EFL_EO_API_SUPPORT 1
#define EFL_BETA_API_SUPPORT 1
#include <Eina.h>
#include <Efl.h>
#include <Elementary.h>
EAPI_MAIN int
elm_main(int argc, char **argv)
{
Evas_Object *win, *textblock;
elm_policy_set(ELM_POLICY_QUIT, ELM_POLICY_QUIT_LAST_WINDOW_CLOSED);
win = elm_win_util_standard_add("Main", "");
elm_win_autodel_set(win, EINA_TRUE);
textblock = evas_object_textblock_add(win);
efl_canvas_text_style_set(textblock,NULL,"DEFAULT='font=DejaVuSans font_fallbacks=SamsungColorEmoji color=#000 font_size=20'");
evas_object_textblock_text_markup_set(textblock, "8️⃣☪️AAA☪︎1234567️⃣");
evas_object_size_hint_weight_set(textblock, EVAS_HINT_EXPAND, EVAS_HINT_EXPAND);
evas_object_size_hint_align_set(textblock, EVAS_HINT_FILL, EVAS_HINT_FILL);
evas_object_show(textblock);
evas_object_move(textblock, 0, 0);
evas_object_resize(textblock, 320, 320);
evas_object_resize(win, 320, 320);
evas_object_show(win);
elm_run();
return 0;
}
ELM_MAIN()Diff Detail
Diff Detail
- Repository
- rEFL core/efl
- Branch
- arcpatch-D9053_1
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 11705 Build 8740: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
I don't think @herdsman can check this comment in a short time. He is not working here these days :)
Comment Actions
@ali.alzyod
Small query here,
why do you need separate caching logic for variation sequence? Can't it be accommodated in the current logic?
Comment Actions
-because variation sequences can vary from ( 0xFE00-0xFE0F , 0xE0100-0xE01EF, 0x180B-0x180D), So I think create hashing tables for these values for each character (or characters that could have variation sequences) will consume more memory, and logic will become more complicated where one Unicode value could have many variation sequences.
-So I thought of binary search as good solution where we will keep old logic as it is, and if character has variation sequence it will be added to variation sequence sorted list, and accessing will be fast specially list will be small for each unicode value.
Comment Actions
Making myself clear,
Memory will not be issue here, only issue I can see is that single Unicode can have multiple variation sequence. So if same unicode with different variation sequence belonging to different font file will fetch you the incorrect font in some cases, if current logic is used.
Am I correct?
If so, then it looks good to me.
Comment Actions
"if same unicode with different variation sequence belonging to different font file will fetch you the incorrect font in some cases, if current logic is used.
Am I correct?
If so, then it looks good to me."
Yes you are
"only issue I can see is that single Unicode can have multiple variation sequence" this is the reason why "Memory will be an issue"
We will need to allocate more memory if we want to create hash-tables (we do not need to allocate all of them at once for each glyph), and it will be more than what we need to allocate for searching small subset of variations
Comment Actions
Sorry, I wasn't precise enough. I mean evas unit test in src/tests/evas/evas_test_textblock.c, so that it get integrated inside ninja test properly.
Comment Actions
For variation sequences test I could not think of unit testing for this feature, you can detect this feature visually only.
Comment Actions
On the one side you *could* check it also visually in a test. On the other side, a test that just uses the feature, checks that the getter returns the same as the setter, checks that there are no errors, checks that there are no crashes, would also be a good start.
Comment Actions
there are no getter and setter for this feature, it uses same as markup get/set.
It is about how to render text
Comment Actions
I am talking about the getter and setter of markup. If the rendering would fail or some parser stuff permits this feature, then there should likely either be a error, or a different returned string. So this can be tested in this way.
Comment Actions
First : I think getter and setter of markup must have error code I am 100% with this option, and it should be used before rendering (check parsed string).
Second: returning error for failed rendering is not convenient (My opinion ), for example when you do not have glyph and render '?' this is not real error, it is that your system does not know how to render it.
For unit test visual option automated way (just an Idea)
render Textblock on Image, save it. with each new build XOR new image with saved one to check if there are change
Comment Actions
I am not talking about a return code.
I am talking about a *printed* error, you can detect those errors, examples can be found in the elementary (efl_ui_suite) testsuite.
(For the visual option, talk to @cedric, there are a few things that are getting difficult here)
Comment Actions
Exactly what @bu5hm4n said. As for the visual test, the easy way with text is just to ask for the object size once the markup is set. If all the characters are properly processed, you will always have the same size. There are already test like that in evas_test_textblock. It isn't perfect, but it ensure that we do not break to much the parsing and sizing of this characters that might not otherwise be seen by anyone during a release cycle.
Comment Actions
I uploaded 6MB file (NotoColorEmoji.ttf), but when I apply the patch its size is 0, do you know what may cause this issue ?
Comment Actions
Could you check whether this patch still passes all the tests now ?
If there is no problem, I'll close soon.
Comment Actions
96%: Checks: 28, Failures: 1, Errors: 0
../src/tests/evas/evas_test_textblock.c:4143:F:Object Textblock:evas_textblock_variation_sequence:0: Failure 'fw_new == fw && fh_new == fh' occur red
I got an error while running tests.
Do I need to do something else or are we missing something ?
Comment Actions
can you please check the size of these files, please? I do not know for some reason it maybe copied when applying the patch as 0 byte
- src/tests/evas/fonts/NotoColorEmoji.ttf
- src/tests/evas/fonts/NotoEmoji-Regular.ttf
Comment Actions
well terminology doesn't barf this time :) evas tests fail for me (along with a bunch of other tests too all barfing on aarch64). :( but this is already the case without this patch. so this certainly improved things vs the last version.