[Libreoffice-ux-advise] [Bug 100100] Emoji toolbar control

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=100100

--- Comment #9 from V Stuart Foote <vstuart.foote at utsa.edu> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.