[Bf-taskforce25] Keyboard Input in Blender 2.5. (Re: SVN commit[19148]: Text Editor back.)

[joe]

I work on a unicode text editor at work, and I can say, it's pretty
complicated.  You need a surprising amount of infrastructure code for
fully supporting unicode; it's a big pain.  For example, in some
languages a logical character may take up more then one unicode code
point (the so-called grapheme clusters), for e.g. certain accented
characters or arabic scripts.  And remember, there are still surrogate
code points (for code points larger then 65,535) in UTF16, even if
they're not common.

I think we could still use UTF8; UTF16 is really only nice because you
can sometimes treat every character unit (whar_t array item) as a
codepoint, but that still doesn't always work, and it's kindof a pain
having to constantly convert from one to the other.

We'd have to handle grapheme clusters in some way; clusters consist of
a base code point, that's modified by subsequent ones.  We could
probably ignore the modifiers, and only render the base character.
Pango supports rendering grapheme clusters, I think, but it comes with
a glib dependancy.

For more information, see
http://books.google.com:2/books?id=wn5sXG8bEAcC&printsec=frontcover&dq=unicode+demystified
that book and http://unicode.org/

Joe

On Sun, Mar 1, 2009 at 2:07 PM, Brecht Van Lommel <brecht at blender.org> wrote:
> Hi Nathan,
>
> On Sun, 2009-03-01 at 22:31 +0200, Nathan Letwory wrote:
>> > * A monospace truetype font was added, since that is needed for
>> >  the text editor. It's Bitstream Vera Sans Mono. This is the
>> >  default gnome terminal font, but it doesn't fit entirely well
>> >  with the other font I think, can be changed easily of course.
>>
>> I think it would be wise here to add a Unicode-capable font right from
>> the first release. This will immediately cut down any potential bug
>> reports about those characters not showing. I already tested with both
>> typing directly into the text editor and by loading a simple test.txt
>> containing the string "äöåÄÖŵ°ëéèôñ". On loading the test.txt simple
>> nothing got printed.
>
> The font has these special characters. It is the text editor that can
> only work with ascii strings currently.
>
>> > * Operators:
>> >    * Insert
>>
>> Related to the font and input is that we'll have to look into handling
>> deadcharacter stuff (to be decided where to handle properly, GHOST?
>> Event/WM manager?).
>>
>> This is important, since some characters on different layouts are done
>> through keycombinations ie, AltGr+9 for ] (AltGr being the right
>> Alt-key) and ie. AltGr+r for the ^-character in text editor. The
>> latter for instance currently will trigger the SCREEN_OT_area_rip
>> operator. Clearly this isn't desirable :)
>>
>> This is something that will not only affect text editor, it will
>> affect the whole of Blender: text fields and hotkeys being the obvious
>> victims.
>
> Indeed, there was some talk about this earlier on the mailing list. The
> WM module seems like the right place to do it. The text editor then
> isn't a good place to test that functionality at the moment but the 3d
> text objects do support more characters.
>
> Not sure how much work it would be to get unicode support in the text
> editor .. converting all arrays to something like a wchar_t may not be
> too hard. We need a convention on what to use when, both utf-8 and
> wchar_t have advantages and disadvantages.
>
> Brecht.
>
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>