On Mon, Mar 25, 2002 at 01:49:51PM +0200, Shachar Shemesh wrote:
For simple bidi support you probably need to implement GetCharacterPlacement. (ExtTextOut has had some basic R->L support added to it only from Windows 2000).
I only tested this on Windows 2000, but on it ExtTextOut correctly renders R->L characters, unless some of the flags are set (for example, the flags that tells it that all language processing is already done.
But you'll probably find most programs don't rely on this and call GetCharacterPlacement to do the re-ordering, then pass the string in display order to ExtTextOut. So I'd have thought that the easiest thing to do would be to implement GetCharacterPlacement and have ExtTextOut call this if ETO needs to do reording.
One thing that I don't know how to make work is changing the default codepage for a WINE application. Is that directly affected from the Unix one? If not, how do I configure it?
Like I said, I got DrawTextW to print Hebrew characters, but not DrawTextA. I suspect that it interpreted the chars as ISO 8859-1, and therefor printed accented latin. From my understanding of the Wine code, this is not due to the X codepage, as Wine calls ExtTextOut for all its text output, and ExtTextOutA simply converts to Unicode and calls ExtTextOutW.
I still feel like a novice in this area, as there are some pretty basic stuff about Wine I feel I don't know. I am slowly getting up to speed to be able to do this properly and with as little impact on the rest of the code as possible.
This doesn't quite answer you question, but if you do a CreateFontIndirect with lf.lfCharSet == HEBREW_CHARSET then calling ExtTextOutA should work as expected.
[It looks to me like DrawTextA is broken. It simply does a MultiByteToWideChar using CP_ACP, I'd have guessed it should use the font's charset instead (equivalently it should call ExtTextOutA). I haven't tested this under Windows though so I could be wrong].
Huw.