https://bugs.documentfoundation.org/show_bug.cgi?id=172646
--- Comment #6 from ady <[email protected]> --- (In reply to Anders Lind from comment #5) > I may be misunderstanding, but the characters I tested are standard Unicode > characters rather than characters from the Private Use Area. > > For example: > > 🌴 = U+1F334 > 👑 = U+1F451 > 💶 = U+1F4B6 > > whereas the Unicode Private Use Areas are U+E000 - U+F8FF, U+F0000 - U+FFFFD > and U+100000 - U+10FFFD. (ref. > https://en.wikipedia.org/wiki/Private_Use_Areas ) > > Are you perhaps referring to some internal representation rather than the > Unicode code points themselves? You are correct. Here is what I meant... In Calc, on a blank empty cell, go to menu Insert > Special Character. Selecting the "Liberation Sans" font (used in attachment 207585 from comment 1), the set of available characters "ends" at U+FFFC. IOW, there is no way to select / insert / search for U+1F334 or any of the other problematic characters that you show in attachment 207585. There is a similar limitation when using the Character Map on a Windows OS. Since the characters are actually shown / displayed within Calc, I assume that the actual font file(s) indeed include these characters. Since this seems to be a regression, then at some point in time Calc was/is limited in some of its built-in functions to handle these "out-of-range" Unicode code points (?). Clearly the functions UNICODE() and UNICHAR() are not limited, but the matching criteria in SUMIF() (and probably other "text-criteria" dependent functions) are currently limited. -- You are receiving this mail because: You are the assignee for the bug.
