Dhrubajyoti Banerjee wrote:
> >1.3: a | repha na
> >1.7: a l- | na
>
> Which should be,
> 1.3: a ra virama |na
> 1.7: a la virama | na
OK, this sounds better. The difference is that, in the second version, the
cursor itself is interpreted as if it was a ZWNJ. So the "virama" (halant)
reveals its presence and the editing becomes easier.
However, I notice that this approach would also change the appearance of the
text while the user simply *moves* on it, without any intention to delete or
add anything. Is this a welcome behavior for Indian users?
I think that it would disturb me to see something change when I didn't do
any editing action. I would be distracted by the visual change, and I'd
remain with the doubt that the software changed my text.
> [...]
> The other product(iLeap) from the same vendor does it as you
> have said and
> makes the conjunct formation ('na' with a repha on top)quite
> strange and amusing for me.
That's what happens if you simply render it according to the rules, without
interpreting the cursor as a non-joiner.
> >- In step 1.7, you have to enter something (virama) to make something
> >disappear (the danda of the la).
>
> Since la has an implicit vowel the halant(virama) is there to
> delete the
> vowel from it. The halant is thus the vowel omission sign
> required for
> characters to combine. Indian home users may not understand
> the technical
> details but they can easily understand that
> la + halant + ja gives you l-ja.
Everybody who can read and write certainly has understood and digested this.
I wonder, however, if this isn't one of those concepts which are so much
basic that one forgets them on the school desk.
Moreover, the concept of <la = half la + danda> may be natural for people
who are used to typewriters and typography. Which is, some of the people who
are more likely to switch to computers.
> >The only counterintuitive thing I see is that, in step 2.1,
> it is not clear
> >whether backspace will delete repha (over ja) or -u (under
> ja). But this is
> >a general ambiguity, when you allow to delete non-spacing marks.
>
> This is a big ambiguity, not a small one, which many Indian language
> developers would have faced. When your cursor is after 'na'
> it is fine.
> When it shifts over 'na' what are you about to remove with
> the backspace,
> the reph or the u?
OK. But this ambiguity exists only for people who have never used the system
before. If the u and the repha glyphs are kept in a normalized order (e.g. u
first, repha after) the users soon learn what they should expect to get
deleted.
> 2.1: a ja -u repha | na
>
> Suppose you do not want to delete anything, and are just
> shifting over
> characters to delete the initial 'a'. Then in your case you
> need to move
> over na, -u, reph, danda, j-. 5 keys.
> If it was handled correctly characterwise the j- danda reph
> -u would be one
> single syllable for the software and one shift would do. 1 key.
This is applicable anyway. The left arrow key and the backspace key do not
necessarily have to behave in the same way: deleting can have a "finer
grain" than moving.
You can also have multiple movement keys, to allow broader or finer
movements. E.g:
- <LeftArrow> moves left a whole syllable;
- <ALT + LeftArrow> moves left a single glyph;
- <CTRL + LeftArrow> moves to the beginning of the whole word.
> Another ambiguity in the above case when you are here
> 2.1: a ja -u repha | na
> is that when you press the left key, visibly nothing will happen
> as both -u and repha are zero width glyphs.
> How do you make sure that the user understands that the
> cursor has moved
> over one glyph?
I depends on how the cursor is visualized. For instance, in addition to a
vertical line, the neighboring glyphs could assume a different color.
Alternatively, if the users accept to see the text "change" while they move
on it, the cursor could have a certain "thickness", and move glyphs apart.
In this case, the exact position would be visualized the way you see it in
my picture (compare steps 2.2 and 2.3).
> > > And I'm done. 8 keystrokes after the cursor down, but
> more efficient
> > > than trying to mess with selecting the repha.
> >
> >More efficient!?
>
> I think more efficient software-wise.
Which is generally not a Good Design Principle (tm) for a visual interface.
> >By the way, your method too requires deleting a non-spacing
> mark (the -u
> >after step 1), and even deleting an invisible mark (the
> virama after step
> >3).
>
> The virama is not supposed to be invisible when the joining
> consonant has been deleted.
OK: another good consequence of turning the cursor into an ZWNJ.
> The character based editing system that we have been
> discussing has been in
> existence for more than one decade now being used in a lot of Indian
> language software. It already has quite an user base in India
> and abroad.
> Complaints against the current system are usually only
> against fonts and
> software handling, not against the system itself. Before
> proposing a new
> 'glyph based editing system' I think a feasibility study of
> user acceptance
> should be done by creating a small application using such a system.
In a sense, applications working that way already exist and have their
partisans. I am talking about the old font encodings such as the Shusha
font.
It is easier to ask people to drop these obsolete *encodings*, if the new
encoding may provide equivalent functionality at the screen/keyboard level.
The nice thing, however, is that there is no need to force everybody to
adopt the same method. Systems could offer both, and let the users chose the
one they feel more at home with.
> >I am talking again about REPHA IN ISOLATION: ISCII has a way of
> >representing
> >it, but Unicode does not. This is needed, even only for
> encoding didactic
> >texts, and a solution to encode it (with ZWJ, probably)
> should be found.
>
> I think the same way it is done in ISCII would be quite okay.
> In ISCII you get it by typing the INV character after ra virama.
> A similiar solution may be provided for, in Unicode, by using ZW(N)J.
Yes, there are many easy solutions. The fact is that this are worth nothing
until Unicode officially adopts one of them.
_ Marco
This archive was generated by hypermail 2.1.2 : Wed Nov 28 2001 - 12:06:16 EST