4 ms·

(Not knowing your startup ill make loads of assumptions here, sorry if I get it wrong) If you are drawing Unicode characters that include a full range of Emoti

(Not knowing your startup ill make loads of assumptions here, sorry if I get it wrong) If you are drawing Unicode characters that include a full range of Emoticons, you are most likely using a platform API provided by Apple/Google/Microsoft or similar. You, like most developers, most likely live in "Big-tech land", so you get this for "free". If you want to port your application to an open source platform or a new upstart platform, where this isn't available, they may not have the resources to draw thousands of Emoticons, so its harder for them to attract you as a developer. Lets say someone is writing a SMS app for something like a PinePhone. SMS is open enough protocol that this is possible. The UI for a chat app is something you can build in fairly short order. There are plenty of open fonts, you can use, but there are no open fonts that have thousands of detailed and sometimes animated Emoticons. Without Emoticons very few people are going to want to use a PinePhone as their main communications device. The amount of effort needed to implement a SMS chat vs a SMS chat + draw all emoticons people use is massive. Unicode, and SMS are both open, but given the size of the Unicode Spec, its effectively shutting out any small player form implementing it. Big tech gets to claim they use open standards, but at the same time make sure no one can threaten them. Its a bit like when Microsoft tried to make a standard for documents so complicated that only word could implement it.

lifthrasiir 6y ago
You seems unaware of why emoji got accepted to Unicode in the first place. Emoji was originated from Japan's three big telcos, which had different sets and encodings of emojis (e.g. some used Shift_JIS extension, some used embedded images via HTML, some used SI/SO sequences). It was already impossible to write a SMS app without accounting for this peculiarity. Unicode thus made this situation much easier, not harder.
mschuster91 6y ago
> If you want to port your application to an open source platform or a new upstart platform, where this isn't available, they may not have the resources to draw thousands of Emoticons, so its harder for them to attract you as a developer. License a commercial font or use Twitter's CC-BY font: https://twemoji.twitter.com/ https://twemoji.twitter.com/ > Unicode, and SMS are both open, but given the size of the Unicode Spec, its effectively shutting out any small player form implementing it. You only need to implement the Unicode spec if you want your own emoji designs.
fastball 6y ago
Are there not any open-source fonts that support the full Unicode spec? You only need to implement glyphs people are actually using. If people are using [some glyphs] from the Unicode spec in your app, yes of course you need to use a font that implements them. How else could it possibly work? What would your alternative be?
- quelsolaar 6y ago
  I think a better solution would have been to only have glyph in Unicode, and then any emoticons would have been implemented by sending embedded images in various chat protocols. Its much easier for a receiver to parse a common image format then to make a font that includes all emoticons. It would also allow users to add their own emoticons, and you wouldn't have any ambiguity of what you are sending. Some facial expression could be argued dont express quite the same thing in all fonts, so there may be something lost in translation between users of different platforms. I found a paper on it! https://brenthecht.com/publications/cscw2018_emojiimpact.pdf https://brenthecht.com/publications/cscw2018_emojiimpact.pdf

lifthrasiir 6y ago

You seems unaware of why emoji got accepted to Unicode in the first place. Emoji was originated from Japan's three big telcos, which had different sets and encodings of emojis (e.g. some used Shift_JIS extension, some used embedded images via HTML, some used SI/SO sequences). It was already impossible to write a SMS app without accounting for this peculiarity. Unicode thus made this situation much easier, not harder.

mschuster91 6y ago

> If you want to port your application to an open source platform or a new upstart platform, where this isn't available, they may not have the resources to draw thousands of Emoticons, so its harder for them to attract you as a developer. License a commercial font or use Twitter's CC-BY font: https://twemoji.twitter.com/ https://twemoji.twitter.com/ > Unicode, and SMS are both open, but given the size of the Unicode Spec, its effectively shutting out any small player form implementing it. You only need to implement the Unicode spec if you want your own emoji designs.

fastball 6y ago

Are there not any open-source fonts that support the full Unicode spec? You only need to implement glyphs people are actually using. If people are using [some glyphs] from the Unicode spec in your app, yes of course you need to use a font that implements them. How else could it possibly work? What would your alternative be?

quelsolaar 6y ago
I think a better solution would have been to only have glyph in Unicode, and then any emoticons would have been implemented by sending embedded images in various chat protocols. Its much easier for a receiver to parse a common image format then to make a font that includes all emoticons. It would also allow users to add their own emoticons, and you wouldn't have any ambiguity of what you are sending. Some facial expression could be argued dont express quite the same thing in all fonts, so there may be something lost in translation between users of different platforms. I found a paper on it! https://brenthecht.com/publications/cscw2018_emojiimpact.pdf https://brenthecht.com/publications/cscw2018_emojiimpact.pdf