Unicode support in QuickGUI

I do remember, that several months ago the topic of including unicode in QuickGUI was discussed. So, how are things standing now? Just to give an example, when I tried to use characters, like greek, cyrillic, umlaut, inverted ?, etc. they just don't show up in the text, moreover sometimes causing a crash. Anything I am doing wrong?

It should be supported, but I haven't had any bug reports, or verified it myself. The GUIManager should have a function like "setSupportedCodePoints". Only supports Code Points will be passed on, when using the "injectCharacter" function. This is supposed to prevent sending unrecognized characters for display.

I wonder why it's causing a crash. Is it possible to PM me and send me the fonts you are using so I can try to repro this? I have no experience using unicode, and I'm using Ogre::Font, so unicode should be supported..

The GUIManager should have a function like "setSupportedCodePoints". Only supports Code Points will be passed on, when using the "injectCharacter" function. This is supposed to prevent sending unrecognized characters for display.


I am not really sure, if that is a good idea. Why should unrecognised characters be rejected? Why should there be unrecognised characters at all? I guess it only depends on, if the character is present in the used font.

Let's say a player of a game with English localisation wants for some reason to use a German Umlaut (Ä, Ö, Ü). Maybe he is German or he just likes exotic names. If it is available in the font, then why not let him use it?

If trying to render a character, that isn't present in the font, causes any problems, maybe it just should be replaced by some other character (? or something).

Zini, you seem to be saying a very logical thought. I think, that's what is used in most games with international audience.
Err, what is needed to get unicode support to QuickGUI? What Font lib does it use?

Zini, you seem to be saying a very logical thought. I think, that's what is used in most games with international audience.


That's how it should be. But unfortunately most games I know do what QuickGUI is currently doing.

I'm not intimate with how true type fonts work. I don't accurately remember what is displayed when you try to type an unrecognized character into a text box. How would I know its unrecognized? I think I remember typing a tilde (`) character, and seeing a long white box. It could be the case that the code point of a tilde belongs to another symbol of the font.

If you can help me figure out how to recognize whether a font supports a given character glyph, I'd be willing to implement this. But I don't think it's possible, at least with my current knowledge.

@Aquatix:

QuickGUI uses Ogre font resource. Just make your own *.fontdef referencing your particular *.ttf file, and in code, tell QuickGUI what code points are available for render.

Ogre::Font uses FreeType. Not the latest, but close, I forget the exact version.

Let's say a player of a game with English localisation wants for some reason to use a German Umlaut (Ä, Ö, Ü). Maybe he is German or he just likes exotic names. If it is available in the font, then why not let him use it?

If they are playing the same game and can see each other, than you will need a font that supports code points for both German and English glyphs. Tell QuickGUI these code points are valid for text input, and it should be done. I can't see an instance when there will be character glyphs in your game where you don't know about them before hand..

I thought about a MMO game with support for english, arabic, and japanese characters used in names. Is this even possible? I can only imagine one large .ttf with glyph points of all languages.

I just remembered the original reason I required specification of acceptable code points for rendering.

When somebody presses Ctrl, Alt, Shift, Caps Lock, F1-F12, etc. what do you write in the text box? Question marks? Hope not!

Hmm, then theoretically-wise it all should work like a charm... Well, gotta try again and then we'll see. Thnx for reply!!

If they are playing the same game and can see each other, than you will need a font that supports code points for both German and English glyphs. Tell QuickGUI these code points are valid for text input, and it should be done. I can't see an instance when there will be character glyphs in your game where you don't know about them before hand.


You are missing the point here. German was only an example. In an international game you should support all languages (or at least as many languages as the available font permits).
But the developer can't be expected to know about all the languages in the world. So he would need to make an arbitrary choice. Or offer an option to set the set of supported glyphs via a config file.
My idea was to forget about the config file and extract the information from the font instead.

Unfortunately it looks like you are right about this one:


If you can help me figure out how to recognize whether a font supports a given character glyph, I'd be willing to implement this. But I don't think it's possible, at least with my current knowledge.


I examined the Ogre source and it looks like there is no easy way to check the existence of a glyph without hacking Ogre. And even if we would do that, it would be horrible inefficient. So better forget about it and stick to the current system.

Edit: the previous edit was nonsense. Guess next time I should become awake first before posting.

But I think I have an idea at what might be going wrong here regarding Aquatix's problem.

Have a look at OgerFont.h:


/** Adds a range of code points to the list of code point ranges to generate
glyphs for, if this is a truetype based font.
@remarks
In order to save texture space, only the glyphs which are actually
needed by the application are generated into the texture. Before this
object is loaded you must call this method as many times as necessary
to define the code point range that you need.
*/
void addCodePointRange(const CodePointRange& range)


If no code point range is given, Ogre assumes 33-166. So, if more code points are added to QuickGUI, they are ignored by Ogre anyway (since you are not calling Ogre::Font:: addCodePointRange in QuickGUI).

You're right, sorry for not mentioning. You have to specify the code point range in the fontdef file for the given font. I'm not familiar with the syntax tho.


code_points nn-nn [nn-nn] ..


(taken from the Ogre manual)

Edit:

So, you have to specify the code points twice. Maybe you could make QuickGUI check instead, if the font supports the code point? (that wouldn't solve the problem I wrote about a few posts above, but at least it would remove the redundancy).