There has been a lot of progress made on the bidi functionality in 
the past month or so, mainly due to much of detailed feedback, 
testing and a couple of patches by several Israeli users. Among the 
main recent developments is the fact that we now run both on non-
bidi and bidi-enabled win32, although there are a couple of issues 
that still need to be resolved on some flavours of bidi-enabled 
windows (this is prooving rather nightmarish, since we not only 
need to be able to develop on Windows, but also on a score of 
different versions of bidi-enabled Windows, and we are unlikely to 
make much further progress in this area unless some developers 
with access to MSVC runing of those particular flavours of 
Windows come on board).

The main issue to work on in the near future is the Word importer, 
but that is equally true for the non-bidi build, since there are 
significant features in AW that the importer does not yet handle, 
and documents that choke it to death -- the importer will feature 
high on my priority list in the run up to the 1.0 release.

The bidi build itself apears stable; I have not experienced a bidi-
related crash for a long time. In the light of that, I would like to ask 
permission to turn the bidi support on by default. If we as a result of 
that experience unexpected problems that could not be easily fixed 
and/or serious performance drop for the non-bidi users, we can turn 
it off again -- any new bidi specific code will continue to be placed 
inside the #ifdef BIDI_ENABLED construct). The main reason why I 
would like it turned on in the mainstream build is that this is the 
only way we can evaluate how it works in the real world. There will 
be some loses, namely noticeably greater memory usage, but 
there should be some gains too, as I have spent much time on 
optimizing the drawing mechanism, which I think is now more 
efficient than that of the non-bidi build.

Tomas


Reply via email to