[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tise-devel] user comments: tise 1.95beta is out
Dear Chris,
thanks for your valuable comments. They hit most of the bugs of Tise.
Some of them I knew, some not.
So fixing the obvious ones (fixed version uploaded to the web site):
1) brla, bsla - fixed
2) blca - not sure if it exists, but processed correctly now.
3) rnya, snya - fixed
Your other points:
> is produced when pressing "c" after "bl". With illegal combinations in
> general, does Tise give the best-guess character?
If current stack is made of less than five letters, like 'sny' or
'brdz', Tise tries to find out if it is a valid wylie sequence and
acts accordingly, sending regulat letter or subjoined one. If such
sequence is not found, it usually sends a subjoined letter. With 5 or
more letters the result is undefined - usually one will get garbage.
In doubtful cases '+' will always add a subjoined symbol to the
vertical stack, while '.' will always break building of a vertical stack.
> b) Special Vowels:
I'm not sure about that. With A, O, E, U it is unambigous, so I can
implement this easily. But with retroflex 'i' I found that it is
natural to type it as 'I' (capital I), while for a-chung it is easier
to type doubled letters (ii). This is a feature of an input method,
not of EWTS as a translit scheme. As soon as we all agree on some
solid standard, I'll stick to that.
> commercial vendors to bundle EWTS with confidence (read, Apple). (did
> you get my earlier email re: this?).
Yes, I did. I use Linux in my work and agree that we should coordinate
our efforts and make vendors find themselves with some widely accepted
standard. Haven't had time to look closer into this, but does your
solution involve Gnome or KDE? Ubuntu is Gnome-oriented, and I believe
KDE is going ahead faster, while a generic solution doesn't have to
depend on either of them.
> Would it be possible to implement the "hypen-vowel" combinations , ie.
> k-i , k-I , kO (I extrapolate from the published rules on "I" that this
> last one shoud be ka, a-chung, naro... and so on with similar output
> with capital U, E)..
It is possible to implement this. So what will be k-i, kI and k-I ?
> + "B" > U+0F56 U+0F60 U+0F72 comment: ba'i (pressing shift-b produces
> this shortcut)
> + "P" > U+0F54 U+0F60 U+0F72 comment: pa'i
> + "F" > U+0F55 U+0FB7 comment: Tibetan translit of Chinese 'f'
> in Lhasa convention
I'd rather think of it as an extension of the standard implementation.
If these are part of standard, it is necessary to implement them. If
not, they belong to UI issues, that is how to customize the standard
input method to users' specific needs. All UI issues I hope to solve
once EWTS engine is fully tested and approved by the community.
> Certainly, there are many gaps in EWTS that need to be addressed.
Fully agree with that, and hope that obvious Tise roughnesses will
help these issues to be addressed ASAP.
> c) retro flex characters:
> I seem to having trouble with some of these in general... are the dual
> shift keys mapped separately? When I type "D" with the leftShift key,
> it works, but not with the rightShift key. Same issues with "Sh". I
> find same issues with other characters, like the halanta (typing
> "?")...rightShift key doesn't do it, but the left one will.
Windows treats left and right Shifts as different keys, even in API
there is VK_SHIFT mentioned. This will take some time to get sorted
out, but it is easy.
> Is there a way to implement the non-breaking space? Though not made
> public within the spec, through email correspondence with Germano and
> others, we decided to make Shift-Space the non-breaking space.
> Secondly, the asterik seems to be giving breaking tseg (f0b) when it
> should give non-breaking tsheg (f0c)
If Shift+Space is NB space, I'll implement it as such. Should I drop
the asterisk as NB space? It seems the bug is related to that I'm
trying to use Shift+Space to toggle Tise on/off.
> e) I had to adjust a processing instruction line in my implementation of
> EWTS Keyman to work with French keyboards as wells as US... does Tise
> already adjust for this, too, so that the key characters map the ouput,
> and not the key codes? (That "w" makes the Tibetan character for "w"
> regardless of where the "w" physically appears on the keyboard).
Not implemented yet. Again, this is planned to be done after EWTS
engine is tested well.
All the best,
Gregory