Reinstate as much of the Windows font-linking behaviour as I can
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sat, 18 Nov 2006 15:10:48 +0000 (15:10 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Sat, 18 Nov 2006 15:10:48 +0000 (15:10 +0000)
commitfe75e5033cd83f2ddc537457d96625044d168433
tree5b3cc086c1cc60de55959c8d0347ede7278c431f
parent7f5749db9ede654f6a9daaebc1bcc7590468a1e0
Reinstate as much of the Windows font-linking behaviour as I can
easily manage, by adopting a hybrid approach to Unicode text
display. The old approach of simply calling ExtTextOutW provided
font linking without us having to lift a finger, but didn't do the
right thing when it came to bidirectional or Arabic-shaped text.
Arabeyes' replacement exact_textout() supported the latter, but
turned out to break the former (with no warning from the Windows API
documentation, so it's not their fault).

So now I've got a second wrapper layer called general_textout(),
which splits the input string into substrings based on bidi
character class. Any character liable to cause bidi or shaping
behaviour if fed straight to ExtTextOutW is instead fed through
Arabeyes' exact_textout(), but the rest is fed straight to
ExtTextOutW as it used to be.

The effect appears to be that font linking is restored for all
characters _except_ Arabic and other bidi scripts, which means in
particular that we are no longer in a state of regression over 0.57.
(0.57 would have done font linking on Arabic as well, but would also
have misbidied it, so we've merely exchanged one failure mode for
another slightly less harmful one in that situation.)

git-svn-id: svn://svn.tartarus.org/sgt/putty@6910 cda61777-01e9-0310-a592-d414129be87e
minibidi.c
putty.h
windows/window.c