atom feed12 messages in [Bf-committers] UTF8 text input s...
FromSent OnAttachments
Brecht Van LommelNov 1, 2011 4:58 pm 
Campbell BartonNov 1, 2011 6:34 pm 
Alexandr KuznetsovNov 1, 2011 7:08 pm 
Campbell BartonNov 1, 2011 9:26 pm 
Jens VerwiebeNov 2, 2011 12:57 am 
Campbell BartonNov 2, 2011 2:40 am 
Jens VerwiebeNov 2, 2011 3:41 am 
Campbell BartonNov 2, 2011 3:56 am 
Jens VerwiebeNov 2, 2011 4:08 am 
KnappNov 2, 2011 4:10 am 
Jens VerwiebeNov 2, 2011 4:11 am 
Dalai FelintoNov 18, 2011 5:09 pm 
Subject:Re: [Bf-committers] UTF8 text input status (on OS X)
From:Alexandr Kuznetsov (
Date:Nov 1, 2011 7:08:10 pm


c) Typing with dead keys (e.g. ¨ + o => ö) didn't work for me. I managed to get it working using NSTextInput, patch here if people want to test, I'm not very confident that this doesn't break something, so some testing would be great:

I think this problem is much bigger here. The dead keys are typed before a real key, but the composed UTF chars are store in the reverse order. Even if we have a buffer for that, it won't solve many problems. For example Chines and Japanese inputs require more closer interaction with the text, rather than simply typing character. Different input methods exist for different languages which are natively supported by OS. But because Blender doesn't use native text fields, they must be implemented by ourselves. For example, MS Pinpyin replaces typed latin characters into chinese when the whole word is complete. Therefore Blender must expose more text interface to Ghost. Ghost must be able to get the current line, cursor, visual position of editing text and then push edited text back. I probably can take care of this project, but it won't be until end of December. Plus I don't know any hieroglyphics languages. There is multiple cross platform implementations of IME. When we were discussing this with JesterKing, he proposed to use SDL. But although it might have ready solution, it is probably hard to integrate in our Ghost, as all SDL must have its own loop. (Anyway, when IME will be implemented, we might get speech recognition and handwriting for free!!)

a) Uppercases character umlaut (e.g. Ü) are not rendered correctly in

the user interface, they do show in 3D text and the text editor. Appears to be a text rendering problem that would happen on all platforms?

Yes. It is a problem on Windows also. Moreover it is a problem exist with precomposed characters. Maybe it is problem of clipping? Anyway, maybe it is good time to switch char render library as was discussed earlier to support bidirectional text. Maybe there are more latent problem with the rendering of hard characters like Chinese or multiple compositions.

Best Regards, Alex