during the development of a plug-in internal preset management system, I recognized the problem that strings received from text edits have a different UTF8 normalization. For example, the character “ä” on Mac is encoded as 0x61CC88 and on Windows as 0xC3A4. So, on Mac, VSTGUI prefers to work with decomposed umlaut characters, however on Windows the precomposed characters are used. This becomes a problem as soon as you wish to store strings persistently in a platform independent way. What I did to overcome this issue, is to modify the function CocoaTextEdit::getText() by returning the precomposedStringWithCanonicalMapping instead of the decomposedStringWithCanonicalMapping. This resolves the issue and yields a platform independent unique UTF8 string handling.
My question now is, what is the reason, why VSTGUI always returns the decomposedStringWithCanonicalMapping? Is there any reason, why this odd behaviour is necessary?