Emoji Support

s/bit/big/

@fraktalizelove Sorry, it was cancelled voluntarily. The voting was already outdated, since Unicode support was already merged into the diaspora* project. I assumed that everyone wanted Unicode support anyway. There isn’t any logical reason not to support that.

Therefore, the discussion should be divided in three parts:

  • Should full Unicode character support be added to diaspora*? The answer is obviously yes.

  • Should Unicode emojis be cross-platform? The answer is obviously yes, but emoji web fonts are currently hard to support. This would be an ultimate solution.

  • Should this cross-compatibility issue be corrected by a library of images like Twemoji? This is the current proposal.

@dumitruursu Very well worded. That’s exactly what I’ve tried to say countless times :slight_smile:

The fourth and ultimate question would be:

  • What font or what library should be used to display emoji characters on all platforms? For a font, we still don’t know the range of possible choices. For libraries, Emoji One and Twemoji are available, and Twemoji support is currently being implemented by @dumitruursu.

@gp emojisymbols.com looks good but like you said they aren’t free. I don’t think colored emojis would integrate well in our current design but I’d support a nice, monochrome emoji font if it is free. (as in “free speech,” not as in “free beer”)

@steffenvanbergerem If only we could find a free equivalent…

@rasmusfuhse Emojis are characters, not letters. No letter would be replaced with images.

Technically they are the same. I find it stupid to have characters in UTF8 that mean like U+26C4 :snowman: “snowman without snow” for example. In my opinion it is not due to encoding to show me a snowman without snow (whatever that might be, a carrot maybe, but that’s another question). But even if there is a character that is meaning to be an image like this snowman, it is still a character and should be displayed as a character to the user. Maybe if we think about accessability U+26C4 has better chances to be understood as a snowman without snow than an image of such a snowman has - just think of a screenreader that is not able to read an image, but that might be able to speak the words snowman-without-snow to the blind user, because it actually knows what this character’s about.

So I think that images in unicode are stupid, but even if someone thinks that those images might be worth for someone to be part of unicode, those images should not be real images like jpeg-graphics, but still be characters. When some clients have problems displaying U+26C4, it is a client’s problem and the software of diaspora should not be responsible to fix other software’s bugs. That’s my opinion.

@rasmusfuhse I see, so you consider letters and emojis as being technically the same. That’s what I wanted to make clear. I thought you were thinking that markup such as :smile: would be replaced with a smile image, which is not the case.

@fraktalizelove The Twemoji library is open source software and as @dumitruursu said, it can be self-hosted if desired.

Here is the Twemoji GitHub repository.

Also, to make all people happy, we can have an option in Settings to stop the replacement happening, and just let them be unicode chars.

@dumitruursu I had the same idea! Thus the “by default” in the proposal. I think those who disagree with the proposal would really appreciate such a feature and I don’t see why they should be forced to see colored emoji pictures.

Would that be hard to implement?

No, definitely not hard to implement.

Then…

@rasmusfuhse @augier @steffenvanbergerem What do you think about this idea? Would you still be against the implementation of a Twemoji-like library if the automatic replacement could be disabled with a kind of “switch” in the settings?

Well, my disagreeing is not very strong in fact. I have my opinion and I accept it more people like this feature. Personally I would use that switch, but it is another opinion of mine that software should not have too many switches, but just work perfect with standard configuration. So I don’t see a need for such a switch.

I think we are worrying too much about the wrong question. If the need for such a switch will arise, the community will just ask for it. But for now, it is safe to assume that such feature is possible. I don’t think that emoji will be such a big problem in the first place.

For those who think that the images do not match the style of diaspora* - worry not, that’s only one CSS filter away.
filter: grayscale(90%);
filter: hue-rotate(90deg);

(I know that somewhere in Germany @jhass cries inside because of my comment)

@dumitruursu However, please don’t make these green aliens the default… They’re hurting my eyes! :stuck_out_tongue:

(I don’t think that’s what he was talking about)

Oh but wait! Does that mean you could make them monochrome?

Yeah, color-wise - we can make them anything; making them monochrome just means to turn the greyscale filter to 100%
The only thing we cannot change easily - is their shape/style.

The only thing we cannot change easily - is their shape/style.

And unfortunately that’s what doesn’t fit well into Diaspora’s UI, regardless of their colour.

They’re supposed to be funny looking symbols, and most emoji that I’m aware of are like that. Phantom Open Emoji have a different style, flatter and a bit edgier. But they are far from “Open” these days, unfortunately. Plus, they only have like… 50 emojis?
Edit: I had some false assumptions here, look below for a new status on Phantom Open Emoji

@dumitruursu Not “funny looking”, but expressive. Akin to manga characters.

And I much prefer Twemojis than the Phantom Open ones you’re talking about.