Re: mined/mlterm ligature joining

[Nadim Shaikli <shaikli at yahoo dot com>]

Arabeyes developers, I just replied to Thomas with the following
email and I attached the screenshots noted within - not sure what
our mailing-list attachment limits are (and I'm guessing I've
exceeded them since I did not see the email get reflected back),
so I'm putting those screenshots on a webpage instead.  Here are
the links to them (they will be there for a limited time only).

  http://www.fakkir.net/~nadim/mined_6_old.jpg
  http://www.fakkir.net/~nadim/mined_6_new.jpg

Sorry Thomas for the multiple posts.

Salam.

 - Nadim

--- Thomas.Wolff siemens com wrote:
> > > 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.

Don't know what to tell ya - it works GREAT here.  Make sure to have
fribidi in your path and to configure mlterm with '--enable-fribidi'.
I also invoke mlterm with,

 $ mlterm -E utf8 --meta=esc 

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

You might be having font problems - make sure to look into which fonts
you are using on your suse vs. the solaris box.

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

It sounds to me like either a compile problem or a setup issue.  mlterm
is solid and I'm (and have been) using it on a daily basis (as are many
others).

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

OK, I'm attaching two screenshots
 1. with the older mined-2000.6 (from your website)
 2. with the newer mined-2000.6 (you mailed)

NOTE: you might want to start naming those things as beta1, beta2, etc.

Mind you the newer version reacts worse (the combining characters
are no longer combined - both upon entry and upon display).
 
> > 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).

With regard to the order - as you see fit.
 
> > > 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...

I'm not sure what would happen in mlterm (I don't see any use for
them).  As for why they are included in unicode - well, unicode is
an all-inclusive beast that doesn't seem to do things very logically
(in my humble opinion) - so you are better off asking them :-)

 - Nadim


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com