Emoji support

There are some emoji in the Small and Phone layouts.
Small: press "12?", then "☺" on the SHIFT key.
Phone: press "12!@" then "1/3" twice
It's a limited selection in both cases, though.

The other layouts don't have any, although there's an older branch were they do:
https://code.launchpad.net/~onboard/onboard/layouts-experiments
IIRC, the problems back then were a) all those new keys dragging down performance, and b) disagreements on if/how to place the emoji button on the main layer.

I believe we would be better off with a scrolling popup list. That way we could offer all the emoji+descriptions without having to add a myriad of keys to each layout. I'll discuss this with Francesco when he's back. He's worked on the emoji support before.

> marmuta wrote:
> There are some emoji in the Small and Phone layouts.

These are black and white Emojis though.

How about using color Emojis like the open source Emoji One set for example:

http://emojione.com/
https://github.com/Ranks/emojione

?

Yes, we discussed that recently. Showing colored emoji would be nice, but there seems to be precious little support for SVG in OpenType on Linux. AFAICT only Mozilla applications can handle emojione or twemoji at the moment. Even emojione-picker uses svg files instead. If there is high-level support for Gtk applications anywhere, I haven't found it yet.
There are options, adding plain svg files (850!) to the Onboard project, or parsing EmojiOneColor-SVGinOT.ttf ourselves (?). I'm not really looking forward to either, though.
Are there any others?

@ marmuta:

I have asked @eosrei, maybe he has some advice, see:

https://github.com/eosrei/emojione-color-font/issues/58

;)

By the way: Are there any plans to move Onboard to GitHub?

Regards

Status changed to 'Confirmed' because the bug affects multiple users.

Thanks, N.W.

> Are there any plans to move Onboard to GitHub?
Not currently. Why do ask?

s/do ask/do you ask/, you know what I mean.

Because most open source projects these days use GitHub.

A lot of users have a GitHub account, so it's easy for them to report issues on a GitHub issue tracker for various projects with a single account.

GitHub also is better designed and more familiar than Launchpad IMHO.

What's also nice is the mentioning feature ( https://github.com/blog/821-mention-somebody-they-re-notified ).

And pull requests also seem to be easier on GitHub?

Oh and..., for the killer feature:

GitHub supports Emojis:

https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

;D

In defense of Launchpad, haha: It may not be as pretty, but is tightly integrated with Ubuntu, open source, and run by Canonical.

I've always expected support for CBLC/CBDT color format fonts in Linux before SVGinOT. It's quicker to implement since it just uses bitmaps, no SVG renderer needed. SVGinOT is the long term choice due to file size, for example a CBLC/CBDT of EmojiOne will be 20MB+.

An option for now is to add emoji support using the existing font rendering system. Both of my fonts provide regular fallback non-color glyphs. They are machine generated, but acceptable IMO. Feature requests could to be filed for support of SVGinOT and CBLC/CBDT in the stack below Onboard. Greatly extends the timeline, but avoids a custom font render system.

Thanks for the quick response, Brad.

I agree, launchpad works quite well for us. There's not really much pressure to move away, currently. Also, I feel, as long as Onboard is installed by default in Ubuntu, we should stay close. The situation may change with unity 8, we'll see.

> I've always expected support for CBLC/CBDT color format fonts
> in Linux before SVGinOT.
Seems you were right, there's support for (what I believe is) Google's CBLC/CBDT in freetype. I got this example here
https://gist.github.com/jokertarot/7583938
to render colored emoji from your emojione-android.ttf.
That could be a possible path forward. Don't know if this is accessible from anywhere higher in the stack.

For SVGinOT there's just this bug report:
https://savannah.nongnu.org/bugs/?46141

I'd still prefer SVG over png for Onboard, though, because most of the UI is freely scalable. All the other images we use as key labels are SVG too.

> An option for now is to add emoji support using the existing
> font rendering system.
That's what we currently do, yes. If there's no reasonable way to get color, we'll just wait for better times.

> Both of my fonts provide regular fallback non-color glyphs.
I've seen that the fonts-emojione Ubuntu package has gray-scale glyphs. Is that a special version of your font or a fallback? They render fine in Onboard, btw.