Description: Inserting an emoticon through the iOS software keyboard doesn't behave as a user would expect if there is existing text in the current paragraph. Steps to Reproduce: 1. Create/open a document in the iOS app 2. Enter some text, e.g. "My dog Rocky " 3. Add an emoticon through the iOS on screen (software) keyboard Actual Results: The existing text becomes unreadable. Expected Results: The emoticon should be added at the end of the text. Reproducible: Always User Profile Reset: No Additional Info: It seems that the font of the whole paragraph is changed - instead only the font for the emoticons who are inserted should be changed.
Created attachment 150308 [details] Video demonstrating the issue
Looking at this now.
In a current build (and presumably 4.1.64), emojis don't seem to show up at all if there are only normal characters before them in the document. But if you enter emoji as the first characters, then they show up. But if you then enter normal characters after, the emojis disappear, etc. Quite a mess.
If I change the current font explicitly to either "Apple Color Emoji" or "EmojiOne Color", and insert an emoji, it shows up. But if I let LO attempt to do its thing and automatically pick a font for emojis (which should pick the EmojiOne Color), it does not show up.
I now notice that also regular desktop LibreOffice on macOS, built from the cp-6.0 branch, does not display the emojis in the same trivial sample document with just A🐶 on a line. In the cp-6.2 and master branches it works, though. So I will have to look for some essential fix to the common code for macOS and iOS that was done between 6.0 and 6.2.
And indeed, if I build the iOS app from the cp-6.2 branch of core and master branch of online, then I see the emoji, too. But probably we don't want to switch to building the iOS app for distribution from those branches quite yet, so it would be good to fix this also in cp-6.0.
But even in an app built from cp-6.2, if I *insert* the dog emoji (and not just open a document that includes it after a plain character, as in "A🐶"), it doesn't show up. Sigh. Oh well, will concentrate on fixing the problem in core:cp-6.0 (and in online:collabora-online-4, if changes are necessary there, too).
Problem could be related to "break iterators". Debugging the code on macOS and iOS in parallel, I see a difference in what happens in GenericSalLayout::SetNeedFallback(). For the string "A🐶", on macOS nGraphemeStartPos is 1, nGraphemeEndPos is 3. On iOS, they are 0 and 3. Which matches the difference I see from debug output elsewhere, on macOS the part of the string with just the emoji is handled separately for glyph fallback, while on iOS the whole string is, which goes wrong.
Ha. I found one very recent fix to exactly the GenericSalLayout::SetNeedFallback() code I mentioned that had not been cherry-picked to the cp-6.0 branch. With that, it works much better. commit 16faad3657fad114aa984f92a14a5f212a2f8ff5 Author: Mark Hung <marklh9@gmail.com> Date: Sun Jun 2 10:00:41 2019 +0800 tdf#107487 fix font fallback for non-BMP characters. Non-BMP characters use two sal_Unicodes. It is necessary to advnace with OUString::iterateCodePoints safely instead of nCharPos + 1. Will have to check what other emoji-related glitches there still are. But it is probably best to file a separate bug for each specific glitch. One that I noticed right away is that if you insert a flag emoji, when you backspace over it to delete it, the code will delete each of the two characters that combine to form the flag separately. For instance the flag emoji 🇨🇭 actually consists of two character, corresponding to the letters "C" and "H". If I understand correctly, the flag glyphs are ligatures implemented in the emoji font, that the two characters corresponding to country codes combine to form, just like the fi ligature in traditional variable-width fonts is formed by "f" and "i". If I backspace over the 🇨🇭, a later "C" in a square appears instead.
The core issue is fixed in 4.1.65 and I agree with Tor, that we should fill seperat bugs for specific issues arround emoticons. I think this issue can be closed now. Thanks a lot to Tor and the Collabora Team for fixing this issue!
And thanks to Mark Hung for the actual commit that needed to be cherry-picked to the branch from which the app is built.