Unicode References
HI Folks,
Can we use Unicode Characters in Anaplan? As of my knowledge, we shouldn't use as it might reduce the performance of the model. Is that true? (I have access to One APP which itself built by Anaplan and I can see Unicode characters over there)
If we can use it, can someone give or suggest the source where to get those from (Standard resource that Anaplan is using, not from Google search 😃)?
Regards,
Kavin.
Answers
-
1
-
This is the advice we got from Michael Gould himself on the use of Emojis some years ago which is still valid
"Aside from the visual impact, these characters will almost certainly cause integration problems at some point with unusual characters being imported/exported from other systems, or names of actions not coming through properly in API calls etc. Many of these characters are not in the Unicode base plane"
Some of the visual impact issues are:
- Emojis don’t render properly and look like a binary file icon
- Characters render differently on different operating systems/browsers
- Bad spacing – icons can be too close to the text, not centered in the space
- Icons can be too small to see clearly
- Causing unnecessary clutter in status fields that make it harder to read the text
- Gratuitous characters in buttons that don’t mean anything
Hope this helps
David
2 -
Anaplan represents Unicode text internally using UTF-16 - the only limitation I know of concerns the use of code points in the supplementary plane (that is, those above 65535) - these are represented by a so-called "surrogate pair" of two code units. So whilst Anaplan has no problem accepting them, if you have formulae that manipulate them (eg LEFT/RIGHT/MID/LENGTH) then they can cause those pairs to be split, or the length in code units can be larger than the length in code points. Supplementary code points are usually very rarely used, but they do include the emojis mentioned by David.
When importing text, it is important to know which encoding is being used by the system producing the file to map the characters into bytes, and to ensure that this encoding is specified when uploading to Anaplan. Some encodings can only represent a subset of Unicode, so I'd recommend using UTF-8 if possible.
When importing data, Anaplan will perform normalization of text when performing matching on name/code. This means that where there are more than one way of representing some text, they are considered the same. Once imported, other operations (such as manual addition of items) do not perform this normalization so some care may be needed.
Non-breaking and other spaces can also cause problems when people aren't aware of them. So in summary supporting Unicode is one thing (and is itself not a simple yes/no question), being able to manage the complexity it introduces can be another. I don't know of any model performance issues related to Unicode, though.
1
