• Add support for Virama

add beta tag

My only concern is: will this work everywhere? I mean, maybe with different system fonts the new position won't be exactly 50.

This should be fixed after D11005

It needs more investigation but for now

Yes you are right

Of course it need's to be fixed.
The example code here works same as the legacy one (which supposed to work fine in the past and never changed).
In my comment I said that this is the same as the legacy, to say it is an implementation issue not an example issue (agreed with what segfaultxavi has said).

In D10955#206461, @segfaultxavi wrote:

The example clearly does not work (the text lines are overlapped and illegible).
This is probably the implementation's fault, not this example's, but do we have any idea of where the problem is? I would like to be 100% sure the problem is not in the example.

remove unneeded headers, fix warning and fixing spelling

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Update Docs

@segfaultxavi @woohyun
what is the usage of const(string) ?
I used "string" type because it is evaluated to "const char *" (see old property in canvas text called bidi_delimiters also use "string" type for "const char*" , for "char *" usually "mstring" used, maybe I'm wrong ? )

Rebase

@zmike
any other comments?

Rename style_set to style_apply
Make all_styles_get read only property

@woohyun
@bu5hm4n
We have closed all the requests.

Update function description
Fix code convention
add more tests

rebase

• update docs

• fix implicit casting int to a unsigned int
• added EINA_SAFETY_CHECK
• updated docs

• fix implicit casting int to a unsigned int

can you check that all branches of the parsing function is checked and tested (also with asan enabled)?

I have tested only new code.

• split style property to set/get functions + fix docs

• split style property to set/get functions + Fix docs

• split style property to set/get functions

update macro to avoid unexpected behaviour

@tasn
I didn't understand exactly what do you mean by "a new widget" ? do you mean all new interface stuff (ex : ui_text) or something else ? if so, no need to work on bugs related to the new interface ?