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). > > 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).
> 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. > 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. -- Tom. ------------------------------------------------------------------------------ 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
