Re: mined/mlterm ligature joining

[Thomas dot Wolff at siemens dot com]

Hello,

> > You wrote:
> > > enter U+0645 (MEEM) then U+064E (FATHA) - the cursor now should stand
> > > right after the U+0645 (the U+064E is a "composing" character and gets
> > > folded into whatever proceeded it), now enter U+0646 (NOON) -- see the
> > > extra space ?
> > I wrote:
> > > No, this looks perfect here, no extra space. It's on SuSE Linux 8.1
> >
> > Can you confirm that this text is handled well now?

> I still see it on solaris.  Could someone else try this and report
> back with findings ?  Download mined-2000.6 from,

My own mlterm installation on Solaris (which I compiled from the package) 
is very buggy overall. It does not apply right-to-left at all although 
it was compiled with freebidi and freebidi is available.
It does not apply character combining either and it also shows stray 
blanks in certain combinations of mined/mlterm options.
Furthermore, it displays wrong glyphs for some characters.

Also I had told you that I don't see any combining character accents 
in my SuSE 8.1 mlterm, although at least the columns are accounted for 
correctly there.

After all, I must conclude that mlterm is still a very buggy piece 
of software and that's certainly the cause of this problem.


So far about problem 1 and mlterm.
Now about remaining mined problems.


> FWIW: mined-2000.6 behaves better.  The extra space (denoted by
> a paragraph symbol) is still there behind (to the left of)
> joining/combining characters (LAM+ALEF), but its gone once one
> presses on the RETURN key.  If you simply move the cursor (up/down,
> left/right) the space stays on - ...
This sounds weird and different from the effect I saw myself.

> ... Looks like you recalculate the
> line upon a carriage return instead of after the character that
> follows combining character.
No.
> Thomas, I can send you a screenshot
> if you like.
Yes, please.

> NOTE again: this only happens when you enter characters,
> if you open a stored file, everything is displayed properly.
Well, with mined 5, this wasn't the case. Maybe you didn't notice 
the mismatch of cursor and logical character position behind the 
joined character; you could actually move the cursor beyond the 
line-end indication which revealed the wrong display.

Nadim, I will send you an updated mined 6 archive which contains 
the final solution, not the preliminary work-around. It might behave 
differently. Please note that I have not yet implemented correct 
handling on the status line (e.g. if you enter a search string).
- About the order of scripts in the keyboard mapping menu, I 
considered that if someone would add lots of additional scripts, 
alphabetic ordering (reverse or not) would hide the important ones 
among many exotic ones.
So I decided to adapt the order to the order of character ranges in 
Unicode which places Arabic last in the current 4 (and thus more 
quickly reached with cursor-up).


> > 2.
> ...
> I think you're looking at unicode's Presentation Form-A and you
> shouldn't (www.unicode.org/charts).  Although its noted as
> "ARABIC Presentation Forms A", that code chart is NOT needed.
> 
> The only code charts of concern with regard to Arabic are,
> 
>  1. Arabic			-- U+0600 - U+06FF
>  2. Arabic Presentation Forms-B	-- U+FE70 - U+FEFF
> 
> Hope that helps.
Yes, thank you. So I suppose that mlterm wouldn't join them even if 
they would appear in a font. I would still be curious why these 
characters appear in Unicode...


Kind regards,
Thomas