----- Forwarded message from [EMAIL PROTECTED] ----- To: Paul Rohr <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: selections and combining characters References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> From: Havoc Pennington <[EMAIL PROTECTED]> Date: 24 Apr 2002 22:18:37 -0400 In-Reply-To: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii
Paul Rohr <[EMAIL PROTECTED]> writes: > Of the three alternatives described in the Unicode book, I think we've > started converging on a rough-but-not-overly-literate consensus that the > least preferable option (for us) would be handling atomic character > boundaries. > The Pango is_cursor_position field currently corresponds to "graphemes" (see page 126). The text on that page says that a grapheme is the logical unit of text and "should behave as units in terms of mouse selection, arrow key movement, backspacing, and so on." In discussion on the list there seemed to be some sentiment that the Unicode grapheme algorithm doesn't give exactly the cursor behavior that some languages expect, so we allow a language engine to override and perhaps modify this. There's also some indication (supported by the last paragraph of section 5.12) that users want to be able to configure this or have it be different in different situations. So we have some idea that Pango (and GTK) will support that eventually. This will introduce more subtle behaviors into GTK that would need to be synced with a custom AbiWord implementation... In any case the is_cursor_position field is defined to correspond to where you should let people move the cursor, so you could certainly just punt the issue to Pango for now. To answer your question, I don't remember if the grapheme algorithm comes up with "cluster" or "stack" or if it varies by language. In any case it avoids the hard one (atomic). Havoc ----- End forwarded message -----
