On Sun, Aug 8, 2010 at 7:33 PM, Tom Hacohen <tom.haco...@partner.samsung.com> wrote: > On Sun, 2010-08-08 at 18:00 +0800, Brian Wang wrote: >> Please use the test source code I previously attached. >> ** Within the elm_entry object (three chinese characters in the front, >> followed by some english letters), click with your mouse on any of the >> chinese characters at the start of the string and check stdout. There >> are garbage characters returned. > I will, terribly busy ATM :P (I need to finish the textblock overhaul > until tomorrow).
That's ok. :-) >> >> I guess the problem is somehow with the usage of Eina_Unicode. Are >> Eina_Unicode strings the same as the usual UTF-8 strings? > No, as stated in the Eina_Unicode docs, Eina_Unicode are unicode code > points (essentially 32bit ints or wchar_t's if big enough). OK. > >> Please find below the backtrace of gdb (r50595 evas) for your investigation. >> The >> new evas_common_font_query_char_at_coords() returns the INDEX of the >> CHARACTER, while the old evas_common_font_query_text_at_pos() returns >> the INDEX of the BYTE of the start of the character. > Yes, but this is ok because we now handle it as an index, and not a byte > index. OK. > >> Ths returned value is kept as _Evas_Textblock_Cursor's pos. Does 'pos' >> mean the >> number of bytes into the string or the number of character into the >> string? I guess the recent discussion of the docs would help here. > > As said, it's ok, because I also changed textblock to conform with that > change. OK. Is Edje handling strings in UTF-8 or Eina_Unicode/Unicode? It seems to be using utf8 seems the use of Eina_Unicode does not exit in Edje code. However, it passes the cursor position (CHARACTER index) to evas_string_char_next_get()... Please find below the gdb backtrace. --------------- #0 evas_common_encoding_utf8_get_next (buf=0x8176558 "中英混合 english mixed with chinese", iindex=0xbfffeecc) at evas_encoding.c:20 #1 0xb7f246bc in evas_string_char_next_get (str=0x8176558 "中英混合 english mixed with chinese", pos=3, decoded=0xbfffeefc) at evas_object_text.c:1298 #2 0xb7926c0c in _edje_entry_cursor_content_get (rp=0x80c6478, cur=EDJE_CURSOR_MAIN) at edje_entry.c:2648 #3 0xb78fa87b in edje_object_part_text_cursor_content_get (obj=0x80b3550, part=0xb7e60bbc "elm.text", cur=EDJE_CURSOR_MAIN) at edje_util.c:2116 #4 0xb7e1b0a7 in elm_entry_cursor_content_get (obj=0x80b3378) at elm_entry.c:1904 #5 0x08048bb4 in _entry_retrieve_clicked_word (obj=0x80b3378) at elm-entry.c:7 --------------- In Frame #1, the 'pos' argument to evas_string_char_next_get() is the CHARACTER index, which is then passed onto evas_common_encoding_utf8_get_next() in 'iindex', which seems to be used as the BYTE index. The usage of the cursor position as the CHARACTER index and BYTE index seems to be mixed up. Maybe in Frame #2, _edje_entry_cursor_content_get() should call a different evas API to reflect the string is in utf8 and pos is in CHARACTERS? -- brian ------------------ Cool-Karaoke - The smallest recording studio, in your palm, open-sourced http://cool-idea.com.tw/ iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
