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:Campbell Barton (
Date:Nov 1, 2011 6:34:20 pm

Hi Brecht,

I cant really give comprehensive answers here since I just got this working on a basic ghost-x11/python/event level, and made sure switching to foreign keyboard layouts resulted in foreign looking keys.

On Wed, Nov 2, 2011 at 10:58 AM, Brecht Van Lommel <> wrote:

Hi all,

I was asked to look at the remaining unicode text issues remaining on OS X. It seems there are some issues specific to this operating system, and some general:

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?

The same issue shows up on X11, though I think its todo with the font, at least if you use the mono-space font it works

Run this in the console and render to see.

bpy.context.scene.render.stamp_note_text = '\u00DC' bpy.context.scene.render.use_stamp_note = True bpy.context.scene.render.use_stamp = True

On a related note, to render latin1 characters I had to add an exceptions to glib's utf8 function, since it would have otherwise returned an invalid char. I did this mainly because paths can have non utf8 characters and the code we had in BLF from ImLib also happened to work this way though it didnt make a special exception.

Guessing this is a freetype/font issue (or some setting we miss) since we pass the unicode chars to freetype without any changes.

b) The text editor does not use the new event->utf8 at all yet, still only event->ascii. It seems the text editor may need major rewriting to support utf8, so this is not intended to work yet?

There has been no attempt to get this working, we have the python console too, I was hoping to have text button input first. for basic text entry and line editing its not too hard, but fore line wrapping, tab spacing etc... this could be quite a bit more work (could be worth looking into a blf/scintilla port instead)

Two OS X issues:

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: d) Typing e.g. ` + o to get ò seems to break various shortcut keys (same issue exists in 2.59). For example pressing ctrl+q does nothing after this, changing window focus or typing other characters makes it work again.