Separate emoji display from system fonts

[nartr1]

Purpose

Use an independent font asset to render emojis within the keyboard.

Why?

My Oneplus 7 Pro does not have the full set of emojis within its system font leading to invalid characters to be displayed within the emoji selection of the keyboard. Due to this being a system font, it is not replaceable without root access. The actual emojis rendered within any text display are still unfortunately missing, however with this patch you can at least see what emoji you are selecting now.

[nartr1]

I'm not a fan of this approach as this increases the size of the app by a factor of 15. Keeping the app light is a goal and adding 10Mb is not acceptable at this point.

I agree. I was incredibly surprised to see that this font was so large given it's supposed to be the standard for emojis. There is another version of the font without colour that could also be used, however it had some odd behaviour where some of the emojis were still the original coloured version(See the first image below). I'll see what I can do to drop the size down (via compression, converting the font, etc.) Is there an acceptable size for the application that I can try and target?

If rendering these emojis is important, I'd suggest distributing the font as a separate app.

Without root access to device, it's unfortunately not possible to install additional system fonts. Or are you suggesting to distribute a fork of this application?

But if the recent emojis are likely not rendered nicely in most other apps, what do you think of removing them from the emoji picker when the font do not support them?

There are additional oddities within the emoji selector(see screenshot below) with my system font, not just missing glyphs. If I cannot reduce the size of the font or work around the oddities then I'd absolutely be open to that solution, but I'd consider that to be a last resort.

[nartr1]

@Julow I've updated the approach here to instead define the font as an asset to be preloaded(Based on this approach here) This will keep the size down for all users that already have the font installed on their device. If the font is not available on the device, it will be fetched from the hosting provider(in this case Google Play Services) during installation (article here as the official docs did not specify "when" the asset is preloaded) Something that I was surprised to see was that even though my device does not render the emojis correctly, based on the installed size of the application it appears that the font is already installed. I'm assuming that since the default keyboard "G-Board" contains these emojis that it would have been loaded from there, but I'm not exactly sure what the original source is.

That being said, if this type of preloading goes against the "doesn't make any network requests" feature stated in the Readme, I'll maintain this as a fork of your application and include a warning and my reasoning regarding it.

[Julow]

Preloaded fonts might be a good option if that doesn't require permissions to use the network and if there's a high chance that the font is shared with other keyboards.

Without root access to device, it's unfortunately not possible to install additional system fonts. Or are you suggesting to distribute a fork of this application?

What I suggested here was to distribute this font file has an other "plugin" application. Let's call it "Unexpected Keyboard Emoji Font", that users can install separately. This would not attempt to change the system, instead the main app would try to communicate with this "plugin" and use the font from it.

[nartr1]

Preloaded fonts might be a good option if that doesn't require permissions to use the network and if there's a high chance that the font is shared with other keyboards.

There were no additional permissions that needed to be added to the application. It appears that the asset preloading is baked in to the installation process.

What I suggested here was to distribute this font file has an other "plugin" application.

Ah I see. Similar to something like "Termux: Styling" then. I personally have never created an app plugin, but I'll see what the process is like and how feasible it would be for this issue when I next get some free time.

[Julow]

Thanks for looking at it! I would be glad to ear from your experiments with plugin apps. If that's too much work, I'd accept the preloaded font approach, guarded behind an option that is disabled by default (perhaps a checkbox on the emoji pane, happy to do that part).