Hi all,
I am new to the mailing list. I am interested in helping out with BiDirectional (Hebrew and Arabic) support. Is anyone currently working on it? Are there any leads? I am quite willing to get a from scratch go at it, but I don't want to fork the effort.
Shachar
On March 20, 2002 10:51 am, Shachar wrote:
Hi all,
I am new to the mailing list. I am interested in helping out with BiDirectional (Hebrew and Arabic) support. Is anyone currently working on it? Are there any leads? I am quite willing to get a from scratch go at it, but I don't want to fork the effort.
One interesting idea floated at the conference was to implement UniScribe (http://www.microsoft.com/typography/developers/uniscribe/default.htm) on top of Pango (http://www.pango.org).
This would be very cool to have.
On Wed, Mar 20, 2002 at 05:51:47PM +0200, Shachar wrote:
Hi all,
I am new to the mailing list. I am interested in helping out with BiDirectional (Hebrew and Arabic) support. Is anyone currently working on it? Are there any leads? I am quite willing to get a from scratch go at it, but I don't want to fork the effort.
Hi Shachar,
Assuming you're using client side rendered fonts then most of the font support for Hebrew/Arabic/whatever should be in the tree, so that you should be able to render any glyph with a Unicode point that exists in the font (I'd like to konw of any problems you find in this direction).
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). There's a Unicode standard bidi ordering algorithm explained in the Unicode book, probably we can borrow the code for this from a library like pango or freebidi.
For more advanced text layout M$ has its Unscribe library see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/uniscr...
I'm very interested in getting non-roman languages working, so if you need any help please let me know.
Huw.
Huw D M Davies wrote:
Hi Shachar,
Assuming you're using client side rendered fonts then most of the font support for Hebrew/Arabic/whatever should be in the tree, so that you should be able to render any glyph with a Unicode point that exists in the font (I'd like to konw of any problems you find in this direction).
Checked that, and it worked ok for Hebrew. I am not sure about Arabic, as it requires special inter-letter dependant rendering.
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.
I'm very interested in getting non-roman languages working, so if you need any help please let me know.
Huw.
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.
Shachar
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.
-
Dimitrie O. Paun -
Huw D M Davies -
Shachar -
Shachar Shemesh