On Mon, Jun 06, 2005 at 04:59:52AM -0400, Helge Hielscher wrote:
On Thu, 02 Jun 2005 15:06:01 -0300, bulia byak wrote:
And if you know the Unicode codepoint, just press Ctrl+U and type it. This method deserves to be mentioned first because it requires no external programs.
Wouldn't it be better to follow ISO 14755 like GIMP and Gnome? http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf
Thanks for bringing that to our attention.
I've now adapted Inkscape's existing unicode entry method to conform to section 5.1 of that standard, with Ctrl-U as the "beginning sequence" and <Ret> or keypad-enter as "ending sequences". I've implemented the recommended behaviour for <space> key.
Differences from gtk (as tested in gedit; gimp 2.2.6 seems the same, though I haven't tested gimp much):
Differences where Inkscape CVS has better behaviour or where Inkscape conforms more to the spec:
- gtk doesn't allow beginning the hex sequence with 0 (contrary to ISO 14755).
- gtk doesn't implement the recommended behaviour for <space>.
- gtk doesn't allow pressing backspace at the hexadecimal level. (Not required by the spec.)
Differences where gtk better implements the spec: None to my knowledge.
Other differences:
- gtk uses press of ctrl and shift as the "beginning sequence", and release of those keys as the "ending sequence", whereas inkscape uses Ctrl-U for begin as it has in the past, and GDK_Return or GDK_KP_Enter as ending sequence.
Ctrl+Shift is presumably more widespread (e.g. it is used in the examples in the spec; though the spec explicitly this as merely an example rather than recommendation). OTOH, it would conflict with Inkscape's widespread use of Ctrl+Shift in shortcuts. E.g. we might want Ctrl-Shift-B to toggle bold. (Also, Ctrl+Shift is harder to implement than Ctrl-U.)
- gtk commits a character and starts the next one as soon as the user types a hex digit that would make a number greater than 0x10fffd; that digit becomes the start of the next hex sequence, unless the digit is zero, in which case `)' is inserted (shift-0). Non-hex-digits are ignored: 123z4 is the same as 1234.
Inkscape CVS commits a character and starts the next one as soon as the ninth hex digit is typed. (The ninth hex digit is then considered the first digit in the next character, similar to gtk.)
If a non-hex-digit is typed, then previous Inkscape behaviour was that unicode entry is cancelled without inserting anything (not even the non-hex-digit). After thinking about this overnight, I decided to adopt gtk behaviour, but retaining <Esc> and Ctrl-U as ways to cancel. (Gtk has no cancel key to my knowledge, though of course one can backspace over the wrongly-inserted character for much the same effect.) Apart from greater consistency with gtk, this is more forgiving on poor motor skills or other causes of mistyping. OTOH, Inkscape's previous behaviour is better for if people didn't mean to initiate unicode entry.
I don't know how gtk behaves if the user is using a non-Latin keyboard. The ISO spec recommends that the first 6 chars of the non-Latin alphabet be usable as hex digits when latin is not available. Inkscape instead forces a `group 0' interpretation of the keystroke, which we hope to correspond to the Latin alphabet. (We do the same thing for shortcuts: our shortcuts are the same in all locales.) Can users of non-Latin keyboards comment on whether you prefer the spec's suggestion, Inkscape's implementation, or have no preference? Do the two conflict? (E.g. are Cyrillic De & Ie (Д & Е) considered the fifth & sixth letters of the Russian alphabet, and are they on the same keys as latin's 4th & 5th letters (D & E) respectively?) Can anyone point to code to implement the spec's suggestion? (I haven't checked gtk sources.)
I believe Inkscape CVS conforms to section 5.1 in all other respects.
None of the other methods in section 5 of the spec are implemented by either Inkscape or gtk to my knowledge; though in both cases one might argue that the availability of the gunichar program or similar would fulfil most of sections 5.3 and 5.4.
pjrm.