Bug 144348 - Remove bundled emoji font
Summary: Remove bundled emoji font
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: ⁨خالد حسني⁩
URL:
Whiteboard: target:7.5.0 inReleaseNotes:7.5
Keywords:
Depends on:
Blocks: Emoji-Button
  Show dependency treegraph
 
Reported: 2021-09-07 06:21 UTC by Heiko Tietze
Modified: 2023-08-15 14:10 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Tietze 2021-09-07 06:21:55 UTC
In bug 105689 comment 46 the question was raised whether to update the "Emojione Color Font" or to use some other.

The currently shipped EmojiOneColor-SVGinOT.ttf has a size of 6MB and seems to be v1.0 [1] or v1.4 according [2]. It has come to EoL in 2018 before v3.0 [3]. The successor [4] is "Twitter Color Emoji SVGinOT Font" from https://github.com/eosrei/twemoji-color-font/releases taking 6MB.

Emojis seems to be a nice playground for designers and many projects exists around this topic [5]. Most become abandoned quickly.

Google's NotoColorEmoji.ttf from https://github.com/googlefonts/noto-emoji/ weights 9.2MB. 


While I personally hate when an application unsolicited installs fonts and vote for putting these add-ons into extensions, we are currently not that flexible. My build has 70MB in 193 fonts and I could bear with adding a few more bytes. Noto sounds to me like the best solution.

[1] fc-query -f '%{fontversion}\n' instdir/share/fonts/truetype/EmojiOneColor-SVGinOT.ttf | perl -E 'printf "%.3f\n", <>/65536.0'
[2] https://github.com/13rac1/emojione-color-font/releases
[3] https://github.com/13rac1/emojione-color-font/issues/71
[4] https://awesomeopensource.com/project/13rac1/emojione-color-font
[5] https://awesomeopensource.com/projects/emoji
Comment 1 Heiko Tietze 2021-09-07 06:24:13 UTC
From the technical POV we should consider bug 140265 and perhaps create an own font (or pick some icons).
Comment 2 Mike Kaganski 2021-09-07 06:31:32 UTC
(In reply to Heiko Tietze from comment #1)
> From the technical POV we should consider bug 140265 and perhaps create an
> own font (or pick some icons).

Please don't. We are not a font forge. This is clearly outside of the project's scope.

And personally I'm for removal of *all* fonts that are not required for the application operation from the package. The fonts that have (some) justification to be kept in the package are:

1. Fonts that are required technically (e.g., OpenSymbol required for Math)
2. Fonts that are required to guarantee metrical compatibility (with wide-used commercial fonts like TNR and Calibri).
3. Fonts used in shipped templates (which is best limited to minimum, and moved to extensions as much as possible, with notices about used fonts there on the related pages).

Emoji fonts are IMO something clearly outside of these necessary fonts.
Comment 3 Heiko Tietze 2021-09-07 06:55:19 UTC
Guess we have to ship some symbols at least to make the Emoji toolbar work. Could imagine a very limited set which becomes enhanced by extensions.
Comment 4 V Stuart Foote 2021-09-07 13:50:24 UTC
Regardless of the font(s) providing Emoji [1] there are two main facets to LO handling it; 1) picking it -- which the emoji.json based panel organizes, as does the Special Character dialog, and the Autocorect based input; and 2) rendering it to canvas.

IIUC actual rendering to document canvas depends on os, with VCL sallayout font fallback and harfbuzz controlled layout to get the correct glyph to canvas. Rendering support for the color font formats (e.g. bug 104403 or bug 105488) needs more dev effort. But EMOJI should render as inline outline/text glyphs otherwise.

Our Special Character dialog will present chart of the base Emoji glyphs for a font selected, but none of the combined modifier attributes.  Likewise the localized autocorrect based ":<emoji>:" replacement Unicode allows keyboard input.

What we need the Emoji panel to do is laydown the correct Unicode sequences. Either single glyphs or with modifiers (as defined in the emoji.json). So the emoji.json based panel is needed both to categorize/organize the Emojis as a UI widget, and to sequence the combining modifier glyphs needed to be rendered in UI and to canvas.

In that sense, no different than sm need for OpenSymbol, we need an Emoji font delivered with LO that matches what is described in the emoji.json we deploy.

Current EmojiOne Color matches the limited emoji.json we currently ship. When/if replacing the font, the emoji.json will need to be replaced to match (possibly needing edits to avoid unsupportable modifier combinations). 

=-ref-=
[1] https://unicode.org/reports/tr51/
Comment 5 V Stuart Foote 2021-09-07 13:58:25 UTC
(In reply to V Stuart Foote from comment #4)

> 
> In that sense, no different than sm need for OpenSymbol, we need an Emoji
> font delivered with LO that matches what is described in the emoji.json we
> deploy.
> 

Likewise an Emoji font that contains the full set of defined Unicode glyphs we provide autocorrect replacements for. If it has an autocorrect :<emoji>: substitution, we need to assure project provides a glyph to render it.
Comment 6 Adolfo Jayme Barrientos 2021-09-07 18:00:23 UTC
I think the task of providing emoji is best handled by the operating system. Noto Color Emoji is provided by default on Ubuntu (and Debian, I think). Segoe UI Emoji is provided by Windows. Apple Color Emoji is provided by macOS. All we need is to ensure we’re compatible with each font in the respective platforms, and drop our outdated shipped font.
Comment 7 Heiko Tietze 2021-09-08 05:38:04 UTC Comment hidden (obsolete)
Comment 8 Rizal Muttaqin 2021-09-08 15:23:32 UTC
(In reply to Heiko Tietze from comment #7)
> (In reply to Adolfo Jayme from comment #6)
> > ...drop our outdated shipped font.
> 
> Likely not possible. And while I agree to implement better system
> integration (and doubt the need for emojis in first place) this might be too
> late here. But can't we create and maintain a small set of icons ourselves? 
> 
> Rizal, Andreas: what do you think?

I agree with Adolfo and have no desire to create another icon set for the emoji.
Comment 9 Heiko Tietze 2021-09-15 19:37:02 UTC
No votes pro update, and the patch to make it non-experimental was abandoned meanwhile. => WF
Comment 10 ⁨خالد حسني⁩ 2022-09-23 12:18:36 UTC
I’d like to revisit the desicion here. My suggestion is to drop the bundled Emoji font altogether, it is a huge file yet outdated and does not keep up with Unicode updates, and both Windows and macOS come with an Emoji font, and Linux or other Unix users probably already have one of the free Emoji fonts.

Also the bundleed font uses embedded SVGs for color glyphs and these are not supported on Linux and we don’t support them in PDF export (bug 105488).

Overall I don't see any much value in bundling such a font.
Comment 11 V Stuart Foote 2022-09-23 14:12:38 UTC
(In reply to خالد حسني from comment #10)

+1, drop the bundled emoji font.  The os/DE provided coverage should suffice for both the :emoji: autocorrect entries and for the emoji.json based toolbar widget.
Comment 12 Heiko Tietze 2022-09-26 10:48:39 UTC
(In reply to Heiko Tietze from comment #0)
> While I personally hate when an application unsolicited installs fonts and
> vote for putting these add-ons into extensions...

(In reply to Mike Kaganski from comment #2)
> And personally I'm for removal of *all* fonts that are not required for the
> application operation from the package.

(In reply to V Stuart Foote from comment #11)
> +1, drop the bundled emoji font.

Do it.
Comment 13 ⁨خالد حسني⁩ 2022-09-26 15:39:11 UTC
https://gerrit.libreoffice.org/c/core/+/140623

Remains is fixing the EmojiFont setting to use a font list so it can pick an appropriate font for each platform, but it is an experimental feature, so low priority for me (incidentally, the EmojiOne Color font is broken on macOS, the glyphs are oversized and render much bigger than their advance widths).
Comment 14 V Stuart Foote 2022-09-26 19:00:25 UTC
(In reply to خالد حسني from comment #13)
> https://gerrit.libreoffice.org/c/core/+/140623
> 
> Remains is fixing the EmojiFont setting to use a font list so it can pick an
> appropriate font for each platform...

So can the hardcoded [1][2] Emoji font and variable added for the emoji.json toolbar picker (GSoC 2016) simply be dropped, and each os/DE would perform its own fallback? 

Or will the picker quit working without a specific Emoji font to pull configuration from? 

We don't want a recurrence of bug 101511, or the whole widget going inactive bcz of no Emoji font configured or viable fallback to build against being identified. But, I guess the whole emoji.json widget configuration may need a refresh anyhow as per bug 105689#c46 we are not anywhere near complete for categorizing the current Unicode 15.0

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Common.xcs?a=true&r=de6f30bc&h=5419#5419

[2] https://opengrok.libreoffice.org/xref/core/sfx2/source/control/emojiview.cxx?a=true&r=3e1e0af3&h=89#89
Comment 15 ⁨خالد حسني⁩ 2022-09-27 03:38:28 UTC
(In reply to V Stuart Foote from comment #14)
> (In reply to خالد حسني from comment #13)
> > https://gerrit.libreoffice.org/c/core/+/140623
> > 
> > Remains is fixing the EmojiFont setting to use a font list so it can pick an
> > appropriate font for each platform...
> 
> So can the hardcoded [1][2] Emoji font and variable added for the emoji.json
> toolbar picker (GSoC 2016) simply be dropped, and each os/DE would perform
> its own fallback? 
> 
> Or will the picker quit working without a specific Emoji font to pull
> configuration from? 

I think we want to chose a color emoji font, if we let regular font fallback work, we end up with mixed color and b/w glyphs e.g. from DejaVu Sans (incidentally this is how the emoji widget currently look for me on macOS, and it doesn’t seem to be using EmojiOne Color font at all). This can be fixed without hard-coding a font name, when bug 150398 gets addressed.

For now I went with the simple option of using a comma-separated list of the three common color emoji font names, "Segoe UI Emoji,Apple Color Emoji,Noto Color Emoji", this should tell LO to fallback to the next font if the first is missing.

> We don't want a recurrence of bug 101511, or the whole widget going inactive
> bcz of no Emoji font configured or viable fallback to build against being
> identified. But, I guess the whole emoji.json widget configuration may need
> a refresh anyhow as per bug 105689#c46 we are not anywhere near complete for
> categorizing the current Unicode 15.0

I’d go far as to suggest dropping the entire feature. Platforms has there own emoji insertion tools (Windows has emoji keyboard, macOS has Character Viewer with an emoji section, Gnome has a similarly-inspired Characters tool), it is not like we are a chat app where people insert emojis all day to need a built-in emoji widget.
Comment 16 Adolfo Jayme Barrientos 2022-09-27 05:32:39 UTC
I concur with Khaled :)
Comment 17 V Stuart Foote 2022-09-27 07:22:44 UTC
(In reply to خالد حسني from comment #15)

> I’d go far as to suggest dropping the entire feature. Platforms has there
> own emoji insertion tools (Windows has emoji keyboard, macOS has Character
> Viewer with an emoji section, Gnome has a similarly-inspired Characters
> tool)...

On Windows the '<Win>+.' entered emoji keyboard *is* fully functional for entry in LibreOffice.  

+1 for me also. No objection to removing the LO emoji.json widget.

It was a good piece of work for a GSoC project but think the os/DE provided widgets have now caught up and are more suited to task. Nothing compelling in the emoji.json based UI to force us to continue to improve it--which it would need to remain relevant.
Comment 18 Mike Kaganski 2022-09-27 07:53:31 UTC Comment hidden (obsolete)
Comment 19 ⁨خالد حسني⁩ 2022-09-27 09:29:53 UTC
(In reply to Mike Kaganski from comment #18)
> Also agree with the last comments wrt removal of the emoji inserter - but
> this is a bit off-topic here, and needs a separate issue with the
> discussion, decision and action :-)

I filed bug 151197 for this.
Comment 20 Commit Notification 2022-09-27 09:31:44 UTC
Khaled Hosny committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/694f8eb1f79ff28a45682c77d7bb88ad9197025b

tdf#144348: Remove EmojiOne Color font

It will be available in 7.5.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 21 Stéphane Guillou (stragu) 2022-12-12 16:48:59 UTC
Fix verified in:

Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: ad085990b8073a122ac5222e5220f8f1d6826dcf
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Thanks Khaled!
Comment 22 Mike Kaganski 2023-08-15 13:26:21 UTC
https://ask.libreoffice.org/t/emojis-lost-colors-now-only-monochrome-after-updating-to-libreoffice-7-5-5/94674/ is a regression likely related to this change. And it's possible, that along with this, we need some set of preferred substitution fonts for emojis, to avoid really bad-looking automatic substitutions.
Comment 23 Mike Kaganski 2023-08-15 13:33:35 UTC
(In reply to Mike Kaganski from comment #22)
> we need some set of preferred substitution fonts for emojis

I meant, not to bundle them, but to hardcode some names usually existing on major platforms...
Comment 24 ⁨خالد حسني⁩ 2023-08-15 14:10:50 UTC
(In reply to Mike Kaganski from comment #23)
> (In reply to Mike Kaganski from comment #22)
> > we need some set of preferred substitution fonts for emojis
> 
> I meant, not to bundle them, but to hardcode some names usually existing on
> major platforms...

I don’t see how this issue is related, The color emoji in the screenshot is Segoe UI Emoji which is a system font, so shouldn't be affected by the removal of a bundled font, but I’d need to see the document and what font it specifies.

The proper way to handle color emoji selection is tracked in bug 150398.