Marco wrote:
>
> In the case of "Arjun", the four steps perform the following changes (see
> again ARJUN.GIF):
>
> 1: a ra virama ja -u na
> 2: a repha ja -u na
> 3: a ja -u repha na
> 4: a j- danda -u repha n- danda
>
>
> So far so good: I see "Arjun" on the screen.
>
> But what if now I want to change "Arjun" into, say, "Aljun"? By the
> "logical" point of view, I should simply delete the ra and enter a la in the
> same position.
>
> But, on my screen, there is no ra at all! Moreover, there is no consonant at
> all before the ja, because the group ra+virama is displayed as a combining
> repha AFTER the j+danda+u group.
>
> Looking at the screen, the natural thing to do is to move to the repha and
> delete it, then move between the a and the ja and insert a half la.
Actually, I would disagree with this. Trying to select and edit a
repha, or any other mark above or below another letter is a pain,
both to implement and from the point of view of a user trying to
work with selection.
My answer to this is that the natural thing to do is to cursor down
before the na to get an insertion point. Then:
backspace backspace backspace backspace la virama ja u
Or, in terms of backing store:
a ra virama ja -u | na
a ra virama ja | na
a ra virama | na
a ra | na
a | na
a la | na
a la virama | na
a la virama ja | na
a la virama ja -u | na
And I'm done. 8 keystrokes after the cursor down, but more efficient
than trying to mess with selecting the repha.
Consider how often people will correct spelling errors, for example,
by backspacing and retyping, rather than trying to select to a
specific spot to correct and then having to reselect back to the
original spot to continue. It is simply more efficient to do it
this way.
And the above example could be even more efficient if the editing
system implemented the backspace/erase function to clobber syllable
parts (or grapheme clusters) instead of character at a time. But
you also have to consider ergonomic issues there. It may introduce
inefficiencies and mistakes if a backspace/erase deletes more
characters than one keystroke's worth of entry. One principle of
low-level editing (without IME input/select/commit operations)
ought generally to be: key key key erase erase erase
should leave you with no change to text.
>
> In order to accomplish a WYSIWYG editing of this kind, Unicode text should
> be preventively converted to a TEMPORARY INTERMEDIATE FORM, less "logic" and
> more "visual".
I'm not suggesting that this isn't also a possible approach to implementing
Devanagari editing -- just that the issue of what a user does to
deal with editing existing text, under the current Unicode model,
isn't that big a deal for repha and its ilk. On the other hand, the
reordrant vowels might well lend themselves to editor extensions that
work in a visual mode as well as a logical mode.
--Ken
This archive was generated by hypermail 2.1.2 : Mon Nov 26 2001 - 12:17:40 EST