[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mined/mlterm ligature joining
- To: Nadim Shaikli <shaikli at yahoo dot com>
- Subject: Re: mined/mlterm ligature joining
- From: Thomas dot Wolff at siemens dot com
- Date: Tue, 11 Feb 2003 13:13:08 +0100 (MET)
- Cc: Thomas Wolff <mined at towo dot net>
- Cc: developer at arabeyes dot org
> > 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
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.
> Thomas, I can send you a screenshot
> if you like.
> 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...