Bug 100100 (Emoji-Button) - Emoji toolbar control
Summary: Emoji toolbar control
Status: RESOLVED FIXED
Alias: Emoji-Button
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha1
Hardware: All All
: medium enhancement
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords: needsUXEval
Depends on: 105689 101511 102271
Blocks: Toolbars
  Show dependency treegraph
 
Reported: 2016-05-28 09:21 UTC by Samuel Mehrbrodt (CIB)
Modified: 2017-05-27 19:56 UTC (History)
5 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 Samuel Mehrbrodt (CIB) 2016-05-28 09:21:02 UTC
It would be nice to have a toolbar dropdown with emojis to select from.

For example see this addon for thunderbird: https://addons.mozilla.org/de/thunderbird/addon/emoji-menu/
Comment 1 V Stuart Foote 2016-05-28 13:35:09 UTC
Great idea!

Perhaps a check box/radio button selection to filter the Special Character dialog?

Also, as majority of Emoji are assigned codepoints described in the Unicode supplementary multilingual plane (SMP), we have issues in displaying emoji with BMP default Liberation Serif. 

And font fallback substitution to use SMP has been a mess of late.
Comment 2 Heiko Tietze 2016-05-29 07:57:01 UTC
What's wrong with the gallery? What is the use case - that frequently happens as it should become a toolbar items? Character sets contains of a variation of emojis?
Comment 3 V Stuart Foote 2016-05-29 13:02:48 UTC
(In reply to Heiko Tietze from comment #2)
> What's wrong with the gallery? What is the use case - that frequently
> happens as it should become a toolbar items? Character sets contains of a
> variation of emojis?

The emoji can be either glyphs from a font family by Unicode codepoint, or could be a full color graphic linked to the same.

Currently we have a selection defined [1] for the auto-correct based tables used for keyboard emoji entry. It places the glyph variant for the currently active font (or fallback font) by Unicode codepoint. And the font can be styled.

But there are literally hundreds of symbols to be drawn from as "emoji" described on the multiple Unicode pages, so yes they might work OK from the Gallery--but which ones?

Suppose we could start with the 900 or so László chose, but think that might be overwhelming in a gallery format.

=-ref-=
[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=d3c12e22aafd30387a20b437d956cafead314ec1
Comment 4 Samuel Mehrbrodt (CIB) 2016-05-30 06:20:57 UTC
(In reply to Heiko Tietze from comment #2)
> What's wrong with the gallery?

The gallery only handles images, not characters (which emojis are).

> What is the use case - that frequently happens as it should become a toolbar items?

I wouldn't suggest it to have it in the default toolbar - maybe as hidden so that users who want it can have it.

> Character sets contains of a variation of emojis?

Can you please explain what you want to say here? I don't get it.
Comment 5 Heiko Tietze 2016-05-30 07:26:48 UTC
(In reply to Samuel Mehrbrodt (CIB) from comment #4)
> > Character sets contains of a variation of emojis?
> Can you please explain what you want to say here? I don't get it.

I wasn't aware that Unicode is bloated by that much emojis (http://unicode.org/emoji/charts/). 

I would still show them in the Gallery. This approach has the advantage of being independent from the character set chosen by the user. And most likely emojis are expected there. However, Stuart's idea to have a filter for the special character widget sounds good as well. That could be implemented with the new design for this dialog (http://user-prompt.com/libreoffice-design-session-special-character/).

In general I'm not excited about the idea. My hesitation comes from the fact that we should keep the toolbar clean. Only the most frequently used functions have to be there. And the use case of emojis is rather a chat, meaning an auto conversion from :-) into the respective symbol at the comments makes sense.
Comment 6 Luke 2016-06-26 16:19:29 UTC
Emojis are Unicode characters. If I insert an emoji, I want it to remain a character, unless I explicitly convert it to a bitmap. The galley should only be used for bitmap images. Mixing up these concepts seems like it would lead to confusion, bugs, and low quality output. Having the option to convert Emojis to bitmap is OK, but it should not be the default behavior.

I'd like to see a new dialog box to handle Emojis separately, although V Stuart's idea would work too.

OS X, Windows, and Android all have native support for emoji. I’d also like to see us use those glyphs whenever possible.
Comment 7 V Stuart Foote 2016-06-26 17:33:48 UTC
Certainly there are options here. Emoji as glyphs for Unicode code points are present in font families as single OpenType and TTF characters.  Those should remain the primary treatment--responding to font selection methods (autocorrect, Alt+x toggle, and Special Character dialgo) and allowing size, color and selection of any other face the font supports.

Probably best that we not try to use Gallery to hold font glyphs. Too unwieldy--and which font?  But Gallery is not "Bitmap" only, and as most Emoji are designed and published as SVG by Unicode codepoint, a selection of SVG rendering of the Emoji graphics could certainly be added to Gallery.

Perhaps the Creative Commons (CC BY 4.0) Emoji art offerings from EmojiOne might be a good source? 

http://emojione.com/wp-content/uploads/assets/e1-svg.zip  

Organizationally it would be simple to add some subset to the Gallery--just stick with the Unicode codepoint as name (Unicode character name as annotation), and group by Unicode block.

Would have to decide which blocks. Maybe "Miscellaneous Symbols and Pictographs", "Emoticons", "Ornamental Dingbats",  "Transport and Map Symbols" all from the SMP. Based on availability and quality of the SVG to go into the Gallery.
Comment 8 Luke 2016-06-28 05:35:56 UTC
If you want to have a section of Emoji-like graphics in the galley, that's fine. But we should not call it emoji. Right now I can text a message with emoji from an Android to an iOS device, and copy that into a web browser to post in a forum. Every app in the process treats the emoji as a character and handles it naively. Our gallery "emoji" would not work into this flow. 

If we’re going to join the party, let’s do it properly, and universally by treating them as unicode characters. This way content that we generate will be universal and work well with all the other mobile and web software that supports emoji.
Comment 9 V Stuart Foote 2016-06-28 12:22:56 UTC
(In reply to Luke from comment #8)
> If you want to have a section of Emoji-like graphics in the galley, that's
> fine. But we should not call it emoji. Right now I can text a message with
> emoji from an Android to an iOS device, and copy that into a web browser to
> post in a forum. Every app in the process treats the emoji as a character
> and handles it naively. Our gallery "emoji" would not work into this flow. 
> 
> If we’re going to join the party, let’s do it properly, and universally by
> treating them as unicode characters. This way content that we generate will
> be universal and work well with all the other mobile and web software that
> supports emoji.

But that is my point, we already handle them correctly in the framework for the Special Character dialog and with the Autocorrect based keyboard entry of the "Emoji" string. To manipulate as Unicode glyphs within streams of text -- that belongs within the Special Character framework or the Autocorrect entry.

For use as "graphics" with a limited selection of artwork -- those should go into the Gallery, or another content panel of the Sidebar (to allow search by codepoint, name or "Emoji" string). Placed into the Gallery they would only be graphics. But you still have to organize them in some sense--why not use the Unicode blocks of codepoints and naming?

Really in that context the only thing that remains Emoji about them is the Unicode codepoint and glyph they'd represent.

Would also suggest that the localized "Emoji" entries in the Autocorrect tables should probably be used to localize the names/labels of glyphs in both GUI contexts and extend Special Character and Gallery to make use of the values for search.
Comment 10 jonathon 2016-06-28 19:03:34 UTC
Rather than an emoji only toolbar, ensure that bug 34882 (https://bugs.documentfoundation.org/show_bug.cgi?id=34882) is fixed.

Emoji are simply a special case of the issue described at
Really basic missing features and enhancements >  Insert Special Characters -> Recent Characters ( https://wiki.documentfoundation.org/Development/Really_basic_missing_features_and_enhancements#Insert_Special_Characters_-.3E_Recent_Characters )
Comment 11 Yousuf Philips (jay) 2016-08-13 21:51:27 UTC
So akshay has began working on this with the following merged patch. The button is hidden in the standard toolbar.

https://gerrit.libreoffice.org/#/c/26700/
Comment 12 Luke 2016-08-16 07:26:15 UTC
In Windows 10, when I click on the "Emojis" button, Writer instantly crashes. Has this been tested on OS X and Windows?
Comment 13 Yousuf Philips (jay) 2016-08-16 08:12:12 UTC
(In reply to Luke from comment #12)
> In Windows 10, when I click on the "Emojis" button, Writer instantly
> crashes. Has this been tested on OS X and Windows?

Yes its reported in bug 101511.
Comment 14 Yousuf Philips (jay) 2016-10-13 20:39:03 UTC
Additional fixes that need to be done are listed in this google doc.

https://docs.google.com/document/d/1MuP_rU2l7YSNAGqFSIb90a_NH05RzPY_gIsGK2Q3j40/edit?usp=sharing