The debate about Indic does highlight important issues for the end user.
(I am not a Hindi reader/writer.)
Hindi text inputted under Notepad in XP exhibits the following behaviour.
Backspacing deletes characters as they appear to be typed.
Pressing delete before characters deletes blocks of characters.
Charlie Jolly
----- Original Message -----
From: "Kenneth Whistler" <kenw@sybase.com>
To: <marco.cimarosti@essetre.it>
Cc: <unicode@unicode.org>; <kenw@sybase.com>
Sent: Monday, November 26, 2001 4:14 PM
Subject: Re: Indic editing (was: RE: The real solution)
> 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 - 13:07:10 EST