On 18 Jun 2002, Alexandre Julliard wrote:
Shachar Shemesh linuxil@consumer.org.il writes:
I am afraid that the consequence of B will be that no packager in his right mind will use that option. As that works in direct contradiction to the reason I entered the WINE project to begin with, I am trying to opt for a better solution. I'm seeing two possible solutions to this problem:
A. If Fribidi was present during compile, check for its existance during run time. If not present, don't enable the run time option.
or B. Copy (port?) Fribidi into the WINE code. It's LGPL, so the license does allow that.
I'd strongly suggest doing B. We need 16-bit Unicode chars anyway so you probably can't use the standard Fribidi. And this way we can share the Unicode tables with the rest of our code instead of duplicating a whole lot of it. All you really need from Fribidi is the algorithms, and these are not going to change often anyway so copying them into Wine shouldn't be too bad.
Your are quite right, Fribidi's main algorithms are not going to change anymore, the things I'm playing with these days are all interface and other side stuff (BTW if you want arabic joining too, things become a little different). The fribidi unicode tables (for just BMP = 16bit) takes something between 2k and 8k (space vs. speed configurable), so don't worry about that too.