Heiko Tietze wrote:The mental rotation is getting really exertive with more complex icons. Please consider to use faces in normal orientation (that makes it easier to read especially for right-to-left readers).

By the way, Asians uses ^^ for Smileys. Is it possible to create another set to cover cultural specifics?

The Icons are only the additional emoticons the standard emoticons are not don yet (looking first for feedback). For cultural specifics, hm I think there should be an other icon set, but I'm not familiar.

Sorry to barge in - I'm not fully aware of how whole the VDG thing works yet - but I wanted to mention that I have some interest in this topic as well. I maintain Konversation, which has unofficial support for KEmoticons. I'm also studying Korean currently, and emoji have become quite popular over there, so I've been following the various proposals to add support for colored glyphs in OpenType for a while, along with some of the early attempts to add support to Qt, but was thinking about expanding KEmoticons as a stopgap solution as well. I'll follow this thread, but it would be great if you could CC me on the code side of things!

Here's a recent free Emoji set btw: http://www.emojione.com/

Heiko Tietze wrote:

andreas_k wrote:...emojis will fit "perfectly" into the overall icon design.

The mental rotation is getting really exertive with more complex icons. Please consider to use faces in normal orientation (that makes it easier to read especially for right-to-left readers).

I agree with Heiko there: Though the tilted emoticons resemble the character sequences they can be derived from better, they are harder to read. One of the biggest benefits of replacing character sequences with emoticon images to me has always been that they are easier to "read" than the titled faces made up of the characters.

There's also the question about whether the design should avoid using gradients, or at least have a gradient-less version. Microsoft's proposal for colored emoji glyphs in OpenType works by stacking multiple mono-colored glyphs from bottom to top, just like manual layer fonts. It's easy to implement and will probably find adoption before the Mozilla+Adobe proposal which involves embedding SVG glyphs into fonts.

colomar wrote:

Heiko Tietze wrote:

andreas_k wrote:...emojis will fit "perfectly" into the overall icon design.

The mental rotation is getting really exertive with more complex icons. Please consider to use faces in normal orientation (that makes it easier to read especially for right-to-left readers).

I agree with Heiko there: Though the tilted emoticons resemble the character sequences they can be derived from better, they are harder to read. One of the biggest benefits of replacing character sequences with emoticon images to me has always been that they are easier to "read" than the titled faces made up of the characters.

I also agree that the more complex sideways emoticons get harder to interpret the more complex they get... But also it does feel innovative, and you could intuit what characters another person used directly from their icons - and I really, really would not like to see that brilliant thought go to waste.

I think the main thing is the noise factor; If we stripped down the icons and more strictly followed what the letters looked like, it might be more visually digestible. Going flat, softening the harsh square effects, and removing the shadows might help make things more easily digestible. It also helps that simplifying the images will also alleviate the issue of making these in bulk.

Then when it comes to the asian-style emoji, they would actually appear vertical ^_^;;;

The main downside to keeping the text-orientation in emoticons is the fact that, technically, we would have *3* directions icons could face;
left... D:
right... : )
and up... O_o!

So there's that, too...
On a side note, this is the most fun I've had in the VDG forum so far.

To be honest, I'd really prefer to go for emoticons which are really easy to identify for the default set. We can (and should!) still have both the Konqis and the tilted emoticons as alternatives for users who'd like to see a little variety in their chat windows. But users who don't care to change their emoticon theme should get something that works well for everyone rather than being too fancy.

Heiko Tietze wrote:The mental rotation is getting really exertive with more complex icons. Please consider to use faces in normal orientation (that makes it easier to read especially for right-to-left readers).

The additional emotics in normal orientation


And a part of the standard emotics. I definitly don't make the cat emotics. sorry. but there are also some icons missing.


feedback.

Thanks for taking normal orientation into consideration, disregarding the fact that I'm not able to assign many of the emojis to a specific mood. Personally, I'm fine with .
Just out of curiosity: Do write RTL folks Smileys in this way "(-: yadot yppah m'I"?

I like the smilies, however some "positive" smilies strike me as a bit grim, but maybe that's just my imagination.

However, what I actually want to do is to highlight something that seems to have been overlooked so far. Hein already commented on it here, I also spoke with him yesterday about this topic and now I want to share my knowledge (Hein may correct my mistakes

Emojis are becoming more and more popular and that why there's some effort to have a standard on how to manage them. KEmoticons work(ed) by replacing certain strings e.g. it would replace ":'(" with *crying face*. Now that there's a set of emoticons in Unicode, it would have to replace "1F606" with *smiling face*. So far so good. However this would only work with KDE applications, 3rd party applications like e.g. GNOME applications would display a different set of emoticons, because they can not access KEmoticons to do the replacing for them.

Now, that's not only a problem that KDE faces, that's why some companies made different proposals on how to handle this. There's a proposal from Microsoft that's relatively elegant and simple: Fonts are already vector files so they propose to make emojis part of the font file. To make it possible to use different colours they propose to have divide each smiley into different parts that are then stacked on top of each other. It's a bit like having the letters "h", "g", "w" and "I", colour them differently and then stack them on top of each other, like so:
This has a bunch of advantages:

1. It works with all applications equally, stacking and colouring of the differnt smiley parts is handeled by the font renderer, which requires very little change in the applications to support it.
2. it's backward compatible with older OpenType fonts, that don't know about these emoticons. One can simply pull the emoticons from fonts that support them.
3. As long as all applications use the same font, they'll display the same set of emoticons.

But it also has one major disadvantage:

1. It does not support gradients

There's also a proposal by Mozilla and Adobe to embed .svg files in the OpenType font file.
The advantages are:

1. All the .svg goodies like gradients are available
2. It would also be application independent

Disadvantages:

1. It's not backwards compatible
2. It's also difficult to implement and would require major changes to the infrastructure

Right now it's not clear with proposal will make it in the end, however, what Hein wanted to ask you is to think about not using gradients in the emoticons. This way they can then be relatively easy integrated into the font file later.

Sogatori wrote:Emojis are becoming more and more popular and that why there's some effort to have a standard on how to manage them. KEmoticons work(ed) by replacing certain strings e.g. it would replace ":'(" with *crying face*. Now that there's a set of emoticons in Unicode, it would have to replace "1F606" with *smiling face*. So far so good. However this would only work with KDE applications, 3rd party applications like e.g. GNOME applications would display a different set of emoticons, because they can not access KEmoticons to do the replacing for them.

Tp me, the two approaches (strings vs. Unicode chars) are not mutually exclusive. Unicode characters would be preferably when inserting emoticons from the GUI so that they are sure to show up correctly for the recipient, but replacing typical character combinations with images should still work for people who just type their emoticons in. What could be done, of course, is to automatically replace the character strings with the corresponding unicode character before sending the message.

Right now it's not clear with proposal will make it in the end, however, what Hein wanted to ask you is to think about not using gradients in the emoticons. This way they can then be relatively easy integrated into the font file later.

As far as I can see, andreas_k's suggestions don't include gradients, so they're on the safe side then.

colomar wrote:Tp me, the two approaches (strings vs. Unicode chars) are not mutually exclusive. Unicode characters would be preferably when inserting emoticons from the GUI so that they are sure to show up correctly for the recipient, but replacing typical character combinations with images should still work for people who just type their emoticons in. What could be done, of course, is to automatically replace the character strings with the corresponding unicode character before sending the message.

You're correct they're technically not exclusive, however KEmoticons is also dated in other ways. It replaces strings with raster assets of a specific size, so it doesn't scale well with different text sizes, which becomes a problem with the wide range of ppi we now have in displays.

If you've done some web dev lately you might have seen the emergence of new syntax and tags to embed images with multiple versions to handle scaling ... and might have noticed how complex they are. Plus they're currently not among the subset of HTML that QText* supports. Using vector assets instead has the usual hinting and performance problems, and that's assuming QText* can embed them and scale them to line height (I haven't tried).

These are all problems the font stack solves, though.

The other consideration is emoticons changing when copying text from one app to another. That can happen with fonts too of course, but because fonts enjoy (or will enjoy, for emoji) wider-spread support than KEmoticons themes, it's easier to achieve consistency.

Overall there's a few compelling reasons to have emoji in the font stack. They're ideograms and part of text, they just happen to be visually more complex type than traditional characters.

As far as I can see, andreas_k's suggestions don't include gradients, so they're on the safe side then.

Nah they're full of gradients, e.g. those shadow falloffs below the eyes and the fill for the open mouths.

Gradients are nice. I'm not saying the full-fidelity design has to do without them. But it might be strategically sensible to consider making it degradable to a gradient-less version. I agree though the current design looks good along those lines.

colomar wrote:To me, the two approaches (strings vs. Unicode chars) are not mutually exclusive. Unicode characters would be preferably when inserting emoticons from the GUI so that they are sure to show up correctly for the recipient, but replacing typical character combinations with images should still work for people who just type their emoticons in. What could be done, of course, is to automatically replace the character strings with the corresponding unicode character before sending the message.

I absolutely hate it when a program suddenly parse my text and turn my writings into a mess with emoticons thrown in!

A colon followed by a 'p' or a 'D' - or any other emoticon-combination - should not automatically be converted into emoticons when a message is sent! That makes the presentation the user sees before sending the message disingenuous, as it is not the message that is actually sent. It just shouldn't be done.

A less worse approach is to convert the text as the user is typing it, but this should be easily configurable. The best approach is to let users insert emoticons (unicode characters) from a menu, and potentially opt-in for having their text be converted (into unicode characters) while typing.

Conversely, a program should not try to be intelligent and parse incoming messages. If the emoticon unicode characters are there, show the emoticon; but if not, the text should be presented to the user as-is.

hein wrote:

colomar wrote:Tp me, the two approaches (strings vs. Unicode chars) are not mutually exclusive. Unicode characters would be preferably when inserting emoticons from the GUI so that they are sure to show up correctly for the recipient, but replacing typical character combinations with images should still work for people who just type their emoticons in. What could be done, of course, is to automatically replace the character strings with the corresponding unicode character before sending the message.

You're correct they're technically not exclusive, however KEmoticons is also dated in other ways. It replaces strings with raster assets of a specific size, so it doesn't scale well with different text sizes, which becomes a problem with the wide range of ppi we now have in displays.

If you've done some web dev lately you might have seen the emergence of new syntax and tags to embed images with multiple versions to handle scaling ... and might have noticed how complex they are. Plus they're currently not among the subset of HTML that QText* supports. Using vector assets instead has the usual hinting and performance problems, and that's assuming QText* can embed them and scale them to line height (I haven't tried).

These are all problems the font stack solves, though.

The other consideration is emoticons changing when copying text from one app to another. That can happen with fonts too of course, but because fonts enjoy (or will enjoy, for emoji) wider-spread support than KEmoticons themes, it's easier to achieve consistency.

Overall there's a few compelling reasons to have emoji in the font stack. They're ideograms and part of text, they just happen to be visually more complex type than traditional characters.

veqz wrote:I absolutely hate it when a program suddenly parse my text and turn my writings into a mess with emoticons thrown in!

A colon followed by a 'p' or a 'D' - or any other emoticon-combination - should not automatically be converted into emoticons when a message is sent! That makes the presentation the user sees before sending the message disingenuous, as it is not the message that is actually sent. It just shouldn't be done.

A less worse approach is to convert the text as the user is typing it, but this should be easily configurable. The best approach is to let users insert emoticons (unicode characters) from a menu, and potentially opt-in for having their text be converted (into unicode characters) while typing.

Conversely, a program should not try to be intelligent and parse incoming messages. If the emoticon unicode characters are there, show the emoticon; but if not, the text should be presented to the user as-is.

We should not ignore people's habits. There is a reason why all IM applications I know (and also many chat and email applications) show typical emoticon strings as emoticons. Yes, they occasionally get it wrong, but apparently not often enough to make many users complain, otherwise at least some developers would have already decided to remove that feature again.
Inserting emojis manually from the GUI is not convenient at all while chatting, and apparently a majority of users value the added convenience of automatically correctly converted strings higher than the nuisance of incorrectly converted ones (i.e. those that were not meant as emoticons).
So yes, both parsing while sending and while receiving should be optional, but I'd clearly vote for opt-out instead of opt-in, because having the feature on is what people expect from other applications.

Okay, so my proposed approach would be to (optionally, on by default) convert certain strings to emoji unicode characters while typing and then sending the unicode characters. That way it would be visible to the user what happens and we'd get all the benefits from the font stack implementation.
In an ideal world where all applications do that, there would be no need of replacing strings in incoming messages because they already contained the unicode characters. However, during the transitional time where still many applications don't do that, I'd still vote for parsing incoming strings and converting them to unicode by default (with opt-out).

hein wrote:

As far as I can see, andreas_k's suggestions don't include gradients, so they're on the safe side then.

Nah they're full of gradients, e.g. those shadow falloffs below the eyes and the fill for the open mouths.

Gradients are nice. I'm not saying the full-fidelity design has to do without them. But it might be strategically sensible to consider making it degradable to a gradient-less version. I agree though the current design looks good along those lines.

Actually, that shadow from the eyes looked like a mistake to me, as I don't see why it should be there. I think it should be removed. The gradient in the mouths doesn't offer enough benefit from my POV to warrant giving up compatibility for it, either. Therefore, I think those emojis can leave out all the gradients without losing anything substantial.

colomar wrote:Okay, so my proposed approach would be to (optionally, on by default) convert certain strings to emoji unicode characters while typing and then sending the unicode characters. That way it would be visible to the user what happens and we'd get all the benefits from the font stack implementation.
In an ideal world where all applications do that, there would be no need of replacing strings in incoming messages because they already contained the unicode characters. However, during the transitional time where still many applications don't do that, I'd still vote for parsing incoming strings and converting them to unicode by default (with opt-out).

I don't disagree; I think adding the Unicode and DoCoMo mappings to KEmoticons is an OK stopgap solution. I think KEmoticons isn't a reasonable approach to *display* emoji even mid-term, though (we'd end up duplicating the complexity of the font rasterizer). I think as a Framework KEmoticons may live on to do the sender-side replacement and offer a simple emoji IME (e.g. a button you can put next to a text field to bring up a popup with emoji, and possibly supports selection by string, just like Pinyin-based IMEs for Chinese do ... or we could work with upstreams to integrate this into ibus, fcitx & co and make sure they look good on KDE). Recipient-side replacement will stick around mainly for backwards compat then.

See also this recent blog post, KEmoticons was also discussed in the comments there: https://blogs.kde.org/2014/09/11/beyond ... workspaces

And David's review request: https://git.reviewboard.kde.org/r/120173/

And keep in mind that people's habits are changing fast because the mobile platforms do emoji input this way, and you probably don't know some of the most-used IM and chat apps out there (do you use KakaoTalk or Line? because tens or hundreds of millions of people do).

colomar wrote:Actually, that shadow from the eyes looked like a mistake to me, as I don't see why it should be there. I think it should be removed. The gradient in the mouths doesn't offer enough benefit from my POV to warrant giving up compatibility for it, either. Therefore, I think those emojis can leave out all the gradients without losing anything substantial.

on the left picture without gradients and right with gradients (nearly every colour had a gradient.


The benefit would be that you can "script" every icon, when you don't have gradients also the shadow was not necessary.