Quote Originally Posted by jamadagni View Post
To be frank, we are working on a proposal for a script which has been allotted space in the SMP roadmap but since this script is still in use our judgment was that putting it in the SMP would hinder easy implementation. From what you say, what I suspected is in fact true. IIRC most Unicode support libraries (such as Qt and ICU) use 16 bits to ostensibly uniquely represent any Unicode character that might be needed. And going beyond FFFF means those libraries cannot cope up anymore... I daresay Trolltech (oops, Qt Software) will not easily accept a request to upgrade QChar to 24 bits. (Or even 17 bits would be sufficient for the SMP?) Let me try...
Oh, I see.

Well, I suspect convincing Qt or any other vendor to change such a basic concept as character will not be easy...

However, if this is your perspective, the current Qt classes can give some support: for instance, QChar methods like isHighSurrogate(), isLowSurrogate(), highSurrogate(uint ucs4), ushort lowSurrogate(uint ucs4), can make the UTF-32 <-> UTF-16 trips more manageable. Also, QString and QTextCodec methods to convert back and forth between UTF-8 and other encodings fully support the full Unicode plane space.

If some standard encoding for your script exists or can be devised, it is also possible to extend QTextCodec to support it, easing semi-transparent conversion between a custom encoding and UTF-xxx.

So, the current situation is not so dark...

I'm afraid, until we all (or we most...) agree that a 'real' character is 32-bit wide (odd sizes like 24 bits have no real chances) and includes properties like direction, joining, separable, etc. there will not be an easy world-wide solution.

Ciao,

M.