TextArea and 4-byte UTF8 characters display strangely

Using 2020r2.1 under Mojave.

This is a problem that occurs with one of my TextAreas. It only occurs if the text I put there contains a 4-byte UTF8 character such as :camera: (U+1F4F7, UTF8: F0 9F 93 B7). What happens then is that the text may display in another size or another font or both.

It should look thus:


Then I have a button that loads a bad string into the TextArea, and it then looks like this:


If I click that button again to put the same string into the TextArea I get this:

Bad-example 2

Note the font change and strange spacing. Reloading the initial string and this happens:


And reloading it again gives the following for ever and ever:


I wondered if anyone had seen this before (as I say, only a problem with the 4-byte UTF8 characters) before I submit a feedback.

I can replicate this on 10.14.6, and can fix it by prefixing the text with " ". So i am guessing the first character being used is changing how NSTextArea is formatting the text. It switches to Monaco font, when looking at the raw RTF generated.

Meanwhile the TextArea faithfully reports that its font is Arial and its fontsize is 13. In fact the IDE has trouble displaying these strings, in just the same way.

Was that a blank? I tried editing the string in the app that is suffering from this, prefixing a blank, and it appeared not to help. I do have a small standalone app ready to submit with a feedback (it’s what I took the screenshots from).

EDIT: I’d say it nearly fixes it. The vertical positioning of the text is still wrong.

The camera character is forcing extra spacing above and below. Text edit also does this. Not sure how easy that is to stop.

Well I’ll bung it in as a feedback. Thanks for the comments.

I would say it is a apple bug, as mbs calls to set the text through nstextarea do the same thing. Setting the nstextarea.textstorage contents might be a solution, though you have to add all the attributes back in.

Sorry if elements are wrong names, on my phone.

Case <https://xojo.com/issue/63934> submitted.