Chinese support

[zuoa]

How to display chinese

[Robert42]

I think the forum might be the right place to ask questions as the probability is higher that other people will see it.

However, Gorilla depends on Ogre and uses Ogre::String. In the current Ogre version, Unicode is not very well supported - so I doubt this will happen.

So the imho cleanest way would be

• to make Gorilla to depend on a different string class
  • Gorilla is designed to depend only on Ogre, so I don't think this will or should happen
• or to wait until the Unicode ist fully Supported by Ogre
  • Would be my personal preference. But looking at the roadmap and issue tracker, I'm afraid this won't happen
• add an own String class to Gorilla
  • Gorilla is designed to be a very small HUD library, not a full feature GUI. So this class would need to be very small.
  • maybe something like this? This class could be only used for Gorilla::Caption and Gorilla::Markup
    • @betajaen, if you like this Idea, please tell me and I will check, whether it's possible to implement it, test it and create a pull request if so)

namespace Gorilla
{
  class UnicodeString
  {
  public:
#if CXX_11
    typedef char32_t value_type;
#else
    typedef unsigned int value_type;
#endif
  private:
    typedef std::basic_string<value_type> internal_type;

    internal_type _string;

  public:
    template<typename iterator>
    String(const iterator& begin, const iterator& end) : _string(begin, end)
    {
    }

    String(const std::basic_string<value_type>& str) : _string(str)
    {
    }

    String(const Ogre::String& ogreString) : _string(ogreString.begin(), ogreString.end())
    {
    }

    size_t length() const {return _string.length();}
    value_type *operator[](size_t index) const
    {
      return _string[index];
    }
  };
}

[betajaen]

I share the same concern with you.

What if we could support via pre-processor an external unicode library?

But at the very least, I suppose work could be done on the Font class, to store glyphs in a large array, and then a manual function for Caption and Markup to read from a non-string class; say a char/short array? It'd be very general but then unicode support could be built on top of that.

[Robert42]

Unicode Library

I don't know whether a Unicode is necessary. Imho, a Unicode library would only become necessary if we started to convert between Ansi, UTF-8, UTF-16, UCS2, UTF-32 and so

We could simply allow to switch via preprocessor between different std::basic_string<> typedefs. How the user gets his unicode data would become his problem :) I'm thinking about something like

#if defined(GORILLA_UNICODE_CXX11) || defined(GORILLA_UNICODE)
  typedef std::u32string UnicodeString;
#elif defined(GORILLA_UNICODE_CXX03)
  typedef std::basic_string<unsigned int> UnicodeString;
#else
  typedef Ogre::String UnicodeString;
#endif

typedef UnicodeString::value_type UnicodeValue;

When handling files, naming and loading an atlas and so I would keep using Ogre::String as Unicode would only add unnecessary complexity here without adding functionality.

Storing Fonts

I actually think Gorilla should simply use std::map instead of arrays. Its Complexity is logarithmic and it would be only accessed when text has changed. In the Gorilla source-code, playing around with ranges would become unecessary.

Alternatively I suggest to create an own Mapping class

• with a extrem fast access for characters within the range defined in the gorilla file using an array
• with an flexible access to characters outside the range using std::map

[betajaen]

I like the Font idea, and at the very least then the Caption and Markup classes can have an 'backdoor' interface to turn in arrays of integers (or shorts) into valid glyphs in the TextureAtlas. If done correctly, then a glyph could be other things apart from a single character, such as emoticons or even icons.

As for a UnicodeString, I'm for it too - but I'm a bit hesitant to comply to a single unicode C++ implementation, hence the 'backdoor interface' but I see no reason for having both to suit both worlds.

Perhaps we should take this discussion to the Ogre forums, and see what other people think?