[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: my Bidi implementation
- To: developer at arabeyes dot org
- Subject: Re: my Bidi implementation
- From: dov at imagic dot weizmann dot ac dot il
- Date: Sun, 14 Mar 2004 00:13:18 IST
- User-agent: Mutt/1.4i
It just shows how detached I am from the code these days. ;-) I
should be more careful with you on the list.
Finding the *optimal* 9 layer lookup sounds like a really tough
optimization problem. I guess I'll have a look at the code to
see what you did. It would be even more interesting finding the
optimal combination between "if"-statements and lookups
automatically. But I'm getting carried away.
On Sat, Mar 13, 2004 at 05:12:16PM -0500, Behdad Esfahbod wrote:
> Well, I just went through the fribidi.c code from the first to
> the last line, to see what I have done ;).
> Dov, you should check it again, I have implemented a
> sophisticated table packing tool based on the very same idea, but
> this time in C, and not bounded to a double lookup. It goes up
> to 9 lookups if you ask! And with 9 lookups it can pack the
> 17*2^16 beast into <2kb.
> Good old days...
> On Sat, 13 Mar 2004 dov at imagic dot weizmann dot ac dot il wrote:
> > Funny, I had kind of a dejavu when I read about "just having a bidi
> > algorithm that work". I had the same feeling a number of years ago,
> > and the result was Fribidi... The question of "why does it have
> > to be so complicated" is a good question, but in a sense it doesn't
> > matter. The only standard that exists is the Unicode one, and the
> > chances of getting the world to accept something that is not standard
> > is very small... What exactly is it that you don't like about
> > FriBidi?
> > Now regarding the implementation, last time I checked Behdad (or
> > was it Owen Taylor?) had implemented a double lookup. First the upper
> > bits are used to select a 128-byte block. The lower bits are then
> > used to lookup into this lower block. A perl program generates the
> > code and has the additional compression to compare the contents of
> > the 128-byte block. If you hit upon a complete block that has
> > already been built (e.g. all 128 bytes are LTR) then you just
> > reference the existing block. Probably this compression has been
> > updated a bit more, but I believe that is still the basic idea.
> > Regards,
> > Dov
> Developer mailing list
> Developer at arabeyes dot org