==============================================================================
From Gaspar Sinai 
Date: 2002-11-19
Need to get an OTF Urdu font and fix possible problem with 
automatic ligation of U+06A9 U+200D U+0627 and U+06A9 U+200D U+0644
optional ligatures. (Yudit: A000x002 and A000x003)
==============================================================================
From Gaspar Sinai 
Date: 2002-11-18
IS_RM is a converter from ISCII to UTF-8 Roman transliteration
and vice versa:

uniconv -encode IS_DV -in hindi-tulasidas.txt  | uniconv -decode IS_RM

You might expect this as a converter between Unicode and Roman
transliteration but it is not.

This may not be a bug - I just thought you might want to know :)
==============================================================================
From: Anirban Mitra <mitra_anirban@yahoo.co.in>
Date: Thu, 17 Oct 2002 09:12:47 +0100 (BST)

    As I have written you in my previous mail,
suppoort of ISCII code pages in yudit will help in
conversion of old ISCII coded documents to unicode. I
am sending a set of mys files (in zip format) I have
made for ISCII encoding in all 11 main Indian
languages supported by ISCII, namely Assamese(is_as),
Bengali(is_bn), Devanagari (is_dv), Gujarati (is_dv),
Kannada (is_kn), Malaylam (is_ml), Oriya (is_or),
Punjabi(Gurumukhi) (is_pj),Telegu (is_tl),
Tamil(is_tm) and recomended Roman Translitteration
(is_rm).
         As I have no formal knowledge of programming,
I have used already existing codemaps as my guide. I
have made corrosponding ".my" files from these '.mys"
files using mytool and found the following bugs, which
are however beyond my capacity to correct.
    (1) All the utf-8 codepoints corrosponding to
ISCII codepoints is defined in Devanagri alone.
Other indian languages do not have all the letters,
particularly Tamil which has almost half the letters
as compared to Devanagari. As a result, though all
lnguages can be converted to Devanagari through these
codepages but the vice-versa is not true. In Bengali I
have replaced the logical substitutes and it is
working fine. Similar exercise in other language
requires a proper knowledge of that language which
unfortunately I do not have.
    (2) These files will not convert ATTRIB code as
defined in ISCII son documents using multiple Indic
scripts can not be converted. However they can be
converted to one at a time.

    (3) The ISCII code pages require a lot of brushing up.
For example, the conversion of 'Soft halant'[=EA=E9
-&gt;094D 200D] and 'Explicit Halant' [=EA=EA
-&gt;094D 200C] got mixed up in Devanagari and is not
added in other maps. Moreover, the Roman
Transliteration map is only good for decoding.
Encoding through Roman would require separate
elaborate section in the mys file. 

Gaspar: 
Some test (TS_RM) is in alpp.isc and alpp.utf8 
files are in the 

   tests/text 

directory.
==============================================================================
Miikka-Markus Alhonen <miikka@tigatieto.com> Wed, 09 Oct 2002 08:45:43 +0300

Still, what should be done eventually (not necessarily at this point),
is normalization. If you have sequences like U+0061 U+0308 U+0323 and 
U+0061 U+0323 U+0308, they should look the same and even be matched   
by the same find expression etc. At the moment, however, they look the
same, if you type the sequences one character at a time (such as with
the "unicode" input). Then if you cut/paste or reload the sequences, they
look different from each other as well as different from the original
appearance, since now the first diacritic is combined with the base
letter while the second is not, and the second diacritic is shown with
the precomposed glyph.

And still, I would very much like the problem of inputting dead
keys get fixed :) It's very hard to get along without being able to 
input a grave, a tilde or a circumflex in key sequences. And I would
have use for the acute, the diaeresis and the cedilla, too...
==============================================================================
Miikka-Markus Alhonen <miikka@tigatieto.com> Sun, 6 Oct 2002 15:38:10 +0300

Write something in the editor window. Then minimize it and restore
again. If the input focus has remained in the editor window all this
time, the cursor isn't blinking anymore and keyboard presses have no
effect. Tooltips still show up just right when you move the mouse on
them. Then, if you press the mouse button on the editor window, you can
start writing text again, but still the cursor does not blink.
==============================================================================
Werner LEMBERG <wl@gnu.org> Mon Jan 01 00:00:00 1997

BTW, just found out that C-d doesn't erase a character but changes
the writing direction.  I wonder that nobody has ever complained
about that!

How can I change the number of lines `PgUp' and `PgDn' are using
for scrolling?

it is a *very* bad idea that yudit 2.1 installs into /usr and not
/usr/local by default!  Even more annoying, there is no `make
uninstall' target to fix it...

Gaspar:
Workaround: 
  ./configure --prefix=/usr/local
==============================================================================
Gaspar Sinai 2002-02-22
------------------------------------------------------------------------------
Indic in Yudit is not supposed to work well with Pango fonts. 
Please use True Type fonts. 
Devanagari and Tamil should have no (serious) problems
with Pango X11 fonts, still Yudit has better support for True Type 
fonts with Open Type layout.
==============================================================================
Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
2002-01-21
------------------------------------------------------------------------------
Yudit doesn't seem to know always, if changes have been made to the buffer
or not. If one opens a file, deletes a character and then presses Undo, the
file is in fact unchanged, even though Yudit doesn't know this (the Save icon
remains red). If one presses a second Undo after this, the file becomes
unchanged. Now, this is a problem e.g. in the following case: 1) open a file 2)
delete a character 3) save 4) delete another character. Now Yudit thinks that
the buffer becomes unchanged only after three undo's, i.e. 1) restore the last
deleted character 2) restore the character before that 3) restore status
"unchanged". So, even though the buffer was saved between the two deletions,
Yudit thinks the buffer is unchanged only if it is exactly the same as when
_first_ opened. For new buffers, this means that a buffer is unchanged only
after it's made empty (!) by undoing, even while the buffer was saved several
times in between...
