Re: [putty]Re: PuTTY details

[Simon Tatham <anakin at pobox dot com>]

> 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 <behdad at cs dot toronto dot edu> 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
<anakin at pobox dot com>    be their own, that they may more properly respect it."