I tried to show that minibidi is not a real bidi implementation by mentioning a few things it misses. Just a short list out of top of my head:
* Takes \Theta(N^2) time for an string of length N. * Does not implement rule L3 at all. * Is not portable: uses wchar_t. * Just works for BMP (plane 0) (in fact dumps core for chars beyond BMP). * Has known bugs handling explicit marks. * Char type lookup is slow as hell. * Is not tested AT ALL. * Updating to later Unicode versions is not any easy. * Has quite a bad design: Table in header file. * Does not expose all functionality of the bidi algorithm. * Has no build system. Is not a library. * Does not follow the standard with respect to line-breaking, shaping, and bidi interaction. And note that this last one is really hard to implement, and is why shaping is not in FriBidi yet... As I already have said lots of times: Bidi/Shaping is not done line by line... And I can express how important these points are, and how much evil is it to duplicate code in different projects. Right now we have only 6 bidi implementations used widely (FriBidi, KDE, Mozilla, OO.o, Java, ICU), and we've got enough headache with them, now go on and send this ugly hack all over different projects... So, in short, is not conforming to standard in any level. behdad On Fri, 21 May 2004, Nadim Shaikli wrote: > I'm not sure I understand (I might have missed some mails or something > since I don't remember this topic so sorry), but what is wrong with > minibidi and is this concern in relation to the shaping inclusion ? > I'm simply trying to understand the rationale noted or is it with > regard to inclusion vs. linking and being an external library, etc. > > I believe it was mentioned as a simple pre-cooked Bidi+Shaping solution > that will get the job done. > > Salam. > > - Nadim --behdad behdad.org _______________________________________________ Developer mailing list [EMAIL PROTECTED] http://lists.arabeyes.org/mailman/listinfo/developer
