==============================================================================
From: Baiju M <baiju@freeshell.org>
Date: Wed, 13 Nov 2002 13:29:53 +0400 (SCT)

But single substitution is not working in Yudit, I tested raghu.ttf
(Devanagari) font , there is some single substitution for
vowel sign I (U093F), its not working, may be a bug.

I am also not expert in this area, so please correct me if anything
I missed here.

Comments:
From: Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
Date: Wed, 20 Nov 2002

The problem with rendering Devanagari that Baiju mentioned is too
technical for me to solve. He was talking about the Chaining Contextual
Substitution type of GSUB, which isn't used in Yudit at all at the
moment (unless I'm mistaken); for more information, see
http://www.microsoft.com/typography/otspec/gsub.htm#CC

This means that e.g. for Devanagari dependent vowel ii U+0940, there
are 6 different glyphs in raghu.ttf, which are used in different
situations. Try for example writing "rii", "kii" and "sii" with the
Devanagari kmap. The loop above the baseline should attach quite
neatly to the vertical stroke of the base letter. Because the widths
of the base letters are different, this can't be achieved without
different glyphs for the vowel itself. So, the context dictates
which glyph to use. The problem with this is that the base letter +
vowel don't form a ligature, but instead the vowel glyph is
substituted just for another vowel glyph, so two glyphs "ka" + "ii"
becomes two glyphs "ka" + another form of "ii", "ra" + "ii" -> "ra"
+ another form of "ii" etc. The glyph numbers for the different
ii-vowels in Raghu are 546 -- 551 (0x222 -- 0x227).

AFAIK, these substitutions should be made _after_ all the other
substitutions and reorderings we are already making.

==============================================================================
From: Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
Date: Tue, 19 Nov 2002 08:54:13 +0200 (EET)
* Open the attached file pgdn-problem.test with Code2000 size 48. Press
PgDn. Nothing happens, since Yudit can't find a paragraph starting at that
point, even though there are many paragraphs starting below. I think
this has something to do with the fact that even pressing up and down
arrows does not move from line to line, but from paragraph to paragraph.

This is very inconvenient, especially as you can not move to the previous
or the next line by pressing left or right arrow. I still think that doing
the expected case in LTR documents, the opposite in RTL and looping cursor
movement in mixed documents would be the best solution. If you don't want
looping, you could always prevent this behaviour by preventing line-to-line
movement all together when the next/previous line's directionality is
*different* from the present one's.

* For some cases, (de)composition needs to be done a couple of times
through. There's for instance \ufb2c, which is defined to be the
precomposed form of \ufb49\u05c1. OTOH, \ufb49 is the precomposed form
of \u05e9\u05bc, so even the long sequence \u05e9\u05bc\u05c1 should
result in the maximally precomposed glyph \ufb2c.
==============================================================================
From: Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
Date: Wed, 13 Nov 2002 

There's a slight problem in inputting with the Devanagari kmap. I think I
have reported this already before, but probably we have both forgotten all
about it.

Try writing "kaa." + Enter. You get "ka" in Latin letters, then an
independent vowel sign "a" in Devanagari, Devanagari danda and finally a
newline. If you type "kaa." + Space, you get "kaa" in Devanagari,
Devanagari danda and a newline. The former should work like the latter.
Apparently with a newline, the used algorithm is less "greedy" than
it should be. The same happens if you do not write any character after
"kaa.".
==============================================================================
From: Anirban Mitra" <mitra_anirban@yahoo.co.in>
Date: Mon, 11 Nov 2002

In modern Bengali, the combination of Ra-Virama-Ya
[09b0+09cd+09af] is rendered as "Ya+Reph form of Ra"
when in middle or end of a word. But in the begining
of a word, they same combination is expected to be
rendered as "Ra + post-base form of Ya". The second
combination is not obtained in Yudit.
I hope you and Mikka will be able to find out a
solution to this.
  
Another bit of information, the people at Microsoft
Typography had not been able to resolve this conflict
in their Unicode Script processor and this is one of
the reason they have not published the specifications
fo Bengali OT font. They code the second combination
(the one which appears in the begining of a word) as
"Ra+ZWJ(200d)+Ya". In that case a separate Open Type
lookup[Ya + ZWJ -> Post base form of Ya] is to be
included with the fonts.

> Regarding the bug of initial form of Ra-Virama-Ya I mentioned
> earliar, the Open Type Bengali Font specs recently put on web [see
> http://www.microsoft.com/typography/otfntdev/bengalot/default.htm 
> ]by Microsoft has prescribed an initial forms feature similar to  
> Arabic to cope with the problem. But few translitterated word use 
> this combination in middle.

==============================================================================
From: Miikka-Markus Alhonen <Miikka-Markus.Alhonen@tigatieto.com>
Date: 2002-11-11

Also, something I have forgotten to mention previously: There should be a
way to tell Yudit which font to use for which script, including the special
clusters. At the moment, if you define many TTF fonts in one virtual font,
the basic glyphs are looked for in the first font where, say, Devanagari
range is available, while clusters are looked for in the first font where
Devanagari OTF directives are available. Often even many OTF fonts differ
in regard to available ligatures. This way a single Devanagari word can
be shown in three different fonts: one part of it in a plain TTF font,
the second part in an OTF font and the third part in another OTF font. You
can see some of this happening in the attached picture, too, where "na" and
"ma" are rendered with a regular TTF font and "ste" with a different font
where OTF substitutions are available (Raghu). Not very neat, especially
if the baseline is on a different height in the different fonts used (this
happens sometimes e.g. when Raghu is used together with Code2000).

==============================================================================
From Gaspar Sinai 
Date: 2002-10-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-10-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.

==============================================================================
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...
