From: tomasfrydrych@yahoo.co.uk
Date: Fri Sep 19 2003 - 02:31:08 EDT
Just a few comments on the recent thread, as I do not have time to
actually code anything at the moment
GetCharacterPlacement(): as far as I recall, the code in question was
there long before the Unicode patch that required Unicows. I suspect
that then it used to be GetCharacterPlacement(), i.e., without the W
suffix. However, the point is at when the function is not available, then
the system has no built in bidi support, so taking the simple ExtTextOut
path is entirely adequate.
XAP_App::BIDI_SUPPORT_GUI, XAP_App::BIDI_SUPPORT_NONE,
XAP_App::BIDI_SUPPORT_FULL:
When the code was originally designed, it envisaged three scenarios: a
system with no bidi support (e.g., English Win98), system where we
get bidi support for the user interface, but need to do bidi processing in
the main window ourselves (gtk2) and a case where the system does
bidi processing for us both in the main window and gui. The latter was
intended for WinNT and friends. Unfortunately, after months of efforts
and struggling with the inconsistent behaviour on the myriad of
different win32 platforms, it became obvious that if we are to get any
consistency in the bidi layout on win32 and cross-platform, we have to
do the bidi processing for the main window ourselves, which on WinNT
and friends means stopping the system calls doing automatic
reordering. The only way this can be achieved is through
preprocessing strings with GetCharacterPlacement().
As a consequence, the the XAP_App::BIDI_SUPPORT_FULL is not
used and I think never will be. It means the test for
XAP_App::BIDI_SUPPORT_GUI within the discussed code could be
done away with, if we get so far, we should always have
XAP_App::BIDI_SUPPORT_GUI.
Tomas
This archive was generated by hypermail 2.1.4 : Fri Sep 19 2003 - 02:46:05 EDT