[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mined - a utf-8 editor (Arabic)
- To: Thomas Wolff <mined at towo dot net>
- Subject: Re: mined - a utf-8 editor (Arabic)
- From: Nadim Shaikli <shaikli at yahoo dot com>
- Date: Tue, 29 Oct 2002 13:47:14 -0800 (PST)
- Cc: developer at arabeyes dot org
On Tue, 29 Oct 2002 18:52:05 +0100 (MET)
"Thomas Wolff" <mined towo net> wrote:
> Hello Nadim,
>
> > The ability to enter Arabic characters works great - well done.
> > The display issues remain (with the menus and the scroll-bar unless
> > disabled, per those screenshots) ...
>
> Yes, I have not done nor tested anything in this respect. I will
> try with mlterm soon but I'm still sure that the menu display problem
> is an mlterm bug (or misdesign) and I can't do anything about it.
Don't know what to say since I'm not sure how those ctrl characters
are supposed to be handled (at worst you can add Left-to-Right directives
or something similar to see if things improve).
> > ... along with the fact that even under mlterm the
> > newly entered Arabic characters are oddly displayed in the wrong order.
> > ...
>
> Concerning the "wrong order": did you invoke mined with option -b?
> Please try and tell me what the difference is. The option should
> be active with mlterm, otherwise both application and terminal would
> each reverse order, effectively messing up everything.
> Mined's default mode, as I said, is intended for a non-right-to-left
> terminal.
> Unfortunately, by the nature of the matter, both modes of operation
> (mined in xterm, mined -b in mlterm) are incompatible with each other
> as also the order of characters in the file would be exchanged.
> So please also tell me what the preferred order of characters in the
> text file is. I think the modes are usually described as follows:
My fault - you are absolutely correct using the '-b' does solve the
input problem (it should be invoked/enabled at all times as far I'm
concerned -- I didn't see any adverse effects for non-arabic files).
Now 'mined' is it very much usable (I recommend all to give it a try).
One minor thing remains, the 'b' (and all other "exception" characters
which enter two arabic glyphs) seem to display an extra space after
'em which should not be there. They're stored correctly, and even
displayed corrected upon reopen; they are simply not being shown
correctly upon entry.
> Text appears as: abc FED xyz (assume DEF is Arabic)
> Logical order is: abc DEF xyz
> Visual order is: abc FED xyz
>
> I'm afraid the preferred storage order of text in the file will
> probably be the "logical order". This can currently be achieved
> with mined -b in mlterm, but not with mined in xterm.
Logical order is what should always be stored. Mined already does that
and so its fine :-)
> I could do some more work to implement that with xterm for mined but
> I'm not sure it that would be worth the effort as you may prefer
> mlterm anyway and we'd perhaps rather get that right.
> Your opinion?
Well, if you'd like to add Bidi (like fribidi.sf.net) then go for it,
but make sure it disable-able. Using mlterm simple gives us bidi and
shaping for free - its completely upto you (are you looking to learn
something new ?)
> Also I'm not sure what it should depend on if the line adjusts to
> the left or to the right in mixed text - this is rather context-dependent;
> should it always be the first character in a line, or the majority
> of characters, or the end of the previous line...?
> What do standards say about this? I have actually not yet studied the
> "bidi" algorithm.
I'd recommend looking at,
http://www.unicode.org/unicode/reports/tr9/
http://fribidi.sf.net
In very very very simplistic (and wrong :-) terms its dependent on the
first character of the line.
PS: do please release 2000.5 at your earliest convenience for others to
play/test.
- Nadim
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/