> On Thu, 29 Jan 2004, Simon Tatham wrote: >> More importantly, a DLL solution is tying the functionality to >> Windows again - if fribidi is going to be used, then it should be >> usable on all platforms.
Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > FriBidi is designed and work on POSIX systems. There has been a > port for Windows system as I mentioned. It uses libtool so you > can compile it under cygwin, OS X, BSD, Solaris, Linux, ... ... PalmOS, EPOC, Windows CE? People already have PuTTY ports for some of these platforms to some extent. I'm not sure I understand why an implementation of the Unicode bidi algorithm should depend on POSIX functionality at all. Surely it's a self-contained computational task which ought to be possible in pure ANSI C, using nothing even slightly OS-dependent? I'm afraid I can't help wondering if a better solution would be to have a custom-written bidi implementation for PuTTY. One reason why I wonder this is that I've just looked at the fribidi sources. It seems to me that a significant proportion of the code in there is not useful in PuTTY: there's a lot of stuff implementing character sets, for example, which is pointless since everything in PuTTY's terminal data is already in Unicode. And we already have a wcwidth implementation and don't need another one. If I were doing this myself, I strongly suspect I would write my own bidi implementation, designed from scratch to be small, totally portable, and self-contained. This way we would avoid any licensing dangers, preserve full portability across any platform anyone ever plans to run PuTTY on, and avoid wasting space. Cheers, Simon -- Simon Tatham "Thieves respect property; they only wish the property to <[EMAIL PROTECTED]> be their own, that they may more properly respect it." _______________________________________________ Developer mailing list [EMAIL PROTECTED] http://lists.arabeyes.org/mailman/listinfo/developer
