TRichViewEdit

Post by **Sergey Tkachenko** » Mon Feb 11, 2013 9:48 pm

I hate to say it, but this problem cannot be fixed immediately.
TRichView uses WinAPI function GetCharacterPlacement, and it fails it this case, so TRichView falls back to non-bidi aware methods of drawing selection.
We plan to implement a basic support of Uniscribe in this year, but we need to complete some other work before, so it will require time.

Graham · Post by **Graham** » Tue Feb 12, 2013 11:34 am

OK. I think that was one of the reasons I updated to Uniscribe. GetCharacterPlacement had a lot of strange behaviour. The project I'm currently working on has a long time scale, so I'll be waiting with anticipation.

Extorian · Post by **Extorian** » Tue Feb 12, 2013 1:02 pm

Unfortunately my project is due shortly.

The only workout around I can think of is to detect the entered key and compare with the character before the caret. If it is a vowel and both characters are same then cancel the entered key at onkeydown by assigning key:=#0.

Graham · Post by **Graham** » Tue Feb 12, 2013 1:45 pm

It's not limited to the same vowel. Any illegal combination that causes the circular dotted character will cause the caret to go to the start of the line.

Also just spotted that if you are entering Hindi, you have to make sure you have selected the correct font otherwise the caret does not move at all.

Extorian · Post by **Extorian** » Tue Feb 12, 2013 2:30 pm

You are right. Its not just Hindi, it happens with any language if the font does not support the unicode characters. Instead of displaying boxes or using the fallback unicode font for the language the caret just sits.

If you change the font to a correct one later you can see that the characters were entered properly. A work around would be to manually detect the unicode range of the incoming characters and compare against selected font and use the fallback font if the range is not supported. But it would be an additional task and it could be done neater if the component did it internally.

Most of the time the dotted characters appear when a diacritic mark is entered without a suitable character. In my case it is usually a vowel and the work around for the double vowels I describe in the previous post reduces the problem with them significantly.

Graham · Post by **Graham** » Tue Feb 12, 2013 3:23 pm

Microsoft Word will select a default font when you select a different keyboard language. This is useful for determining which font to use for which language.
When it comes to Uniscribe, one of the routines checks for a valid font for the text supplied, if it fails your program just selects the default font. That way you can just select Arial and type any language. The user thinks its Arial but what is displayed may not be.

Extorian · Post by **Extorian** » Tue Feb 12, 2013 4:46 pm

Yes, Word and other software does this using the font fallback mechanism. It is part of the Uniscribe system.

This msdn article describes the process for an application to use the font fallback mechanism.

http://msdn.microsoft.com/en-us/library ... s.85).aspx

The default fallback fonts are hard coded in the Uniscribe system and cannot be changed.

Graham · Post by **Graham** » Tue Feb 12, 2013 5:44 pm

I've not heard of the fallback fonts being hard coded before. I just keep a list of default fonts and when ScriptShape fails I set the appropriate font for that language.

Where is there a list of default fallback fonts? The acticle you refer to doesn't mention it.

Extorian · Post by **Extorian** » Tue Feb 12, 2013 7:54 pm

You can find it here http://msdn.microsoft.com/en-us/goglobal/bb688134.aspx

The last line of the section on font fallback

"Font fallback is internal to Uniscribe, and applications cannot add new fallback fonts or modify existing ones."

I haven't seen an official list of the fallback fonts. I don't think it has been made public by Microsoft. [/quote]

Post by **Sergey Tkachenko** » Wed Feb 13, 2013 3:21 pm

The described problems are the reason why bidirected text is not supported by default. GetCharacterPlacement (used for support of biditext) is a very capricious function. And the worst of all, in the most of cases it's not possible to determine when it fails.
Actually, it is required for Arabic an Hebrew text only.
And WinAPI does not allow to configure font fallback (it seems it is activated only for text strings having some specific characters).

Unfotunately, we are very busy to complete current works (such as DocX export, and RVMedia), so we cannot start working on Uniscribe support right now.

Graham · Post by **Graham** » Wed Feb 13, 2013 3:52 pm

The time scale is not a problem for me. I have about a year before I start to panic.

I'm not sure I understand about automatic font fallback with Uniscribe. I have always checked for missing Glyphs after the call to ScriptShape and then adjusted the font if necessary. Still that will be your problem to solve, not mine. Maybe I was supposed to perform some function before ScriptShape to determine if my font was valid.

One of the things you will have to watch out for is complex characters. Sometimes a single character is made up of multiple Unicode values.

When in doubt, see how Microsoft Word handles the situation. They seem to have got their act together now regarding complex languages.

Extorian · Post by **Extorian** » Wed Feb 13, 2013 4:42 pm

Well, out of the components I have evaluated for use in the project, your component does bidi the best. So even if it is not complete, I am going to have to go with yours. At least you are giving us the straight news. Thanks for that.