[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fribidi question
- To: <developer at arabeyes dot org>
- Subject: Re: fribidi question
- From: Behdad Esfahbod <behdad at bamdad dot org>
- Date: Sun, 6 Jan 2002 10:52:46 +0330 (IRT)
On Sun, 6 Jan 2002, Chahine M. Hamila wrote:
[snip]
> I will if needed, thanks:) In any case, the problem is I don't have an x86
> running GNU/Linux right now to test it, so I can't know if my rendering
> engine is right. It seems attributes and character codes are swapped
> according to endianness in the screen map, so if confirmed, it would mess up
> some of my indices and border conditions. I've been working on a Linux PPC
> since the only PC that ran Linux here had a bad hard disk crash, so I'll have
> to wait til it is tested on PC in order to commit it to CVS and upload the
> new tarball. That's a max of ten days, when I move again, but it would be
> silly to wait that long since the program is ready. The other problem is
> minor, the one that we discuss next,
If you do not need a console to test it, you can test it under
sourceforge.net's compilefarm, it's a very nice one, I tested fribidi
there on machines that I couldn't find around ever.
> > > The bug is in computing the cursor position when approximating bidi
> > > (yes, bidi approximation was finally included and Akka has become a very
> > > extended superset of Acon).
> > Good news, I'm really waiting to see what it will do, I know the
> > problems of simulating a bidi console well..
>
> I still advise against the use of the bidi approximation;)
> I included it with Nadim's encouragement because I thought it could be scary
> to run Akka and Acon side by side in case a bidi approximation is needed
> (when viewing a web page with Lynx for example) and because it is better to
> approach bidi using a UAX#9 conformant implementation like fribidi's than
> Acon's one. That said, since it's impossible to have an exact bidi ordering
> below the application level and edition in a bidi approximation mode would be
> buggy in the general case, I made monodirectional modes the default. So we
> still have to study the reverse bidi algorithm offered by ICU in order to be
> compatible with monodirectional RTL the way UAX#9 is compatible with
> monodirectional LTR, formally specify it the way UAX#9 is, and eventually
> integrate a sample implementation in fribidi for example.
Good idea, but currently we are working on the bidi algorithm itself,
there is enough tasks to do, that we cannot work on reverse-bidi right
now, any one will do this?
> > (snip)
> > You are right, the last element of L_to_V map is the place of the last
> > character of input str, in visual_str.
>
> Thanks Behdad. In that case, I must have it wrong on a border condition,
> because the data I obtained was a constant:/ Will check it later.
>
> > (snip)
> > postition_L_to_V_list has type FriBidiStrIndex which has been
> > typedefed as int, then 32bit, not 16, try to use the new interface
> > please.
>
> How long do you think it would take to have the new fribidi in the testing
> section of Debian at least?
Well, I never looked at testing section of Debian, how should I do?
> How long for RPM packages?
fribidi-0.9.1 released 10 Dec 2001, and the Mandrake Cooker rpm was
ready by Dec 21, then it shouldn't be more than two weeks.
> This is a rather
> important change, but I want Akka's install to be as user friendly as
> possible, or it won't meet any significant audience, so these are important
> considerations for me.
> Regards,
> Chahine
Yours,
--
Behdad
16 Dey 1380, 2002 Jan 6
[Finger for Geek Code]