Page 1 of 1

Problem with TRichViewEdit and BiDiMode

Posted: Fri Sep 05, 2008 9:28 pm
by DickBryant
A user who is using a TrueType Hebrew font (only chars 0-255, no Unicode) sent me this to illustrate the problem. I have confirmed that the control is set to BiDiMode = rvbdRightToLeft using this command:

QMemo.Clear;
QMemo.BiDiMode := rvbdRightToLeft;

Note that SOMETHING happens because of the odd behavior of the cursor. He's using a regular Arial font for this:

It does the following. If I type “My name is Ingo” then the following happens:

1) I type “My” and press space. It starts on the LEFT border in right-to-left direction

2) After I press space the space is inserted before (left) of “My” and the cursor jumps there, too

3) If I type the next letter “n” then the cursor jumps again right to “My” [+space] and here I type “name” in conventional left-to-right order

I verified that if I time

"Now is the time"

that is exactly what I get - not the expected "emit eht si woN"

Can you help?

TIA

Dick

Posted: Sat Sep 06, 2008 8:04 am
by Sergey Tkachenko
This is by design.
Exactly the same happens, for example, in Notepad in right-to-left mode (Right Ctrl + Right Shift).
English letters are strictly LTR characters.
Space is neutral character.
If the default mode is RTL, bidimode of neutral characters is RTL (except for the case when they are surrounded by LTR characters).

Posted: Sat Sep 06, 2008 12:17 pm
by DickBryant
Is there any way to force all characters from 0 - 255 to enter 'real' RTL? Customer wants to use a font that can be represented as all 8-bit characters so that it can then be exported for use with another program which doesn't support Unicode - i.e. must be strictly ANSII text.

Posted: Mon Sep 08, 2008 4:52 am
by Sergey Tkachenko
I guess you mean 'real' LTR (left to right). Sorry, no, because they are not. Spaces and other punctuation are used in RTL languages as well as LTR languages. If the default mode is RTL (right to left), it is expected that the majority of text will be Arabic or Hebrew, may be with some LTR citation.
If you do not want punctiation to be RTL by default, change BiDiMode = rvbdLeftToRight. Either for the whole document, or for the given paragraph (ParaStyles[].BiDiMode) or for the given text fragment (TextStyles[].BiDiMode).
If you use RichViewActions, they have actions for this.

PS: Even if you do not use Unicode, it does not means that text from RichView can be exported in ANSI text files lossless. It's because RichView document can contain text of different character sets (code pages). RTF export solves this problem, though.

Posted: Mon Sep 08, 2008 1:09 pm
by DickBryant
No, really I mean RTL. I want to have a True-Type (8-bit characters) font that I want to be entered RTL (it's Hebrew Characters). I have BiDiMode = rvbdRighttoLeft but only the 'neutral' character positions are entered RTL. Any way to force all 256 characters to be rendered RTL?

Posted: Mon Sep 08, 2008 2:16 pm
by Sergey Tkachenko
Not only neutral, but also RTL characters (Arabic and Hebrew).
Sorry, there is no way to display LTR characters (like English characters) RTL. Only by entering them in backward order.

Posted: Mon Sep 08, 2008 4:17 pm
by DickBryant
How does the control (System?) know that the character is an RTL character vs. a LTR character? I.e. if I have a set of Hebrew characters that are located in the positions 0 - 255 is there a way to 'tag' these as RTL within the font information itself?

Posted: Wed Sep 10, 2008 3:03 pm
by Sergey Tkachenko
TRichView uses GetCharacterPlacement function to get character classes (for ordering text items and calculating caret positions).
There is more easy to use function: GetStringTypeEx.
As for drawing text in one text item, TRichView relies on Windows text drawing functions (text is drawn as a whole string, not character by character).

Posted: Sat Sep 13, 2008 12:40 pm
by DickBryant
Thanks for the additional information, Sergey. I guess I'll just have to abandon this work-around. Folks will have to use the standard Unicode fonts for RTL languages. These, of course, work fine.

Dick