From: SourceForge.net <no...@so...> - 2010-08-06 16:48:09
|
Bugs item #3040720, was opened at 2010-08-06 18:48 Message generated for change (Tracker Item Submitted) made by makarius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3040720&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: editor core Group: normal bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Makarius (makarius) Assigned to: Matthieu Casanova (kpouer) Summary: Incorrect handling of Unicode outside BMP ("surrogates") Initial Comment: Handling of unicode characters outside the "Basic Multilingial Plane" (U+0000 to U+FFFF) does not really work in TextArea and a few other custom made text boxes of jEdit, e.g. the "Console" plugin. Instead of navigating text according to "code points", as explained in http://download.oracle.com/javase/6/docs/api/index.html?java/lang/Character.html jEdit usually refers to plain-old UTF-16 Chars for caret movement, deletion etc. The following example in Console/Beanshell illustrates this: buffer.insert(0, "\uD835\uDC9C\n") This produces a calligraphic letter A, e.g. use the STIX fonts http://www.stixfonts.org to see it on the screen. Positioning the caret at the end of the first line, a single BACKSPACE will only delete the second "surrogate" character in the internal representation, leaving the first one standing alone. Thus the content of the buffer becomes malformed in the sense of this funny Java text representation. This has been reproduced in various official jEdit versions, such as 4.3.2. It seems that the most basic text fields of Swing can handle these newer unicode points. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=3040720&group_id=588 |