Why emoji changed with Discourse upgrade

Site Feedback
2

I’m surprised this is an issue at all. Why wouldn’t the software just present the Unicode sequences and let the browser render the emoji as it wants? This avoids all issues, because the rendering will by done by OS code on the reader’s computer.

If there is a reason why Discourse needs to send images instead of Unicode sequences (maybe it has characters that don’t appear in Unicode), then yes, I agree completely with the decision. There are copyright issues around fonts and artwork, so anything distributed with software needs to be either public domain or licensed. (Open source fonts still requires a license, but they usually include no-cost licenses for those who comply with the terms.)

Quick test. Three emoji presented two ways:

  • As Discourse markdown (entered via the editor menu)
    • Grinning Face: :grinning_face:
    • Heart Eyes: :heart_eyes:
    • Face Savoring Food: :face_savoring_food:
  • As direct Unicode (entered via Apple’s emoji palette):
    • Grinning Face: U+1F600: :grinning_face:
    • Smiling Face with Heart-Eyes: U+1F60D: :heart_eyes:
    • Smiling Face Licking Lips: U+1F60B: :face_savoring_food:

Weird. They look different in the editor, but when I post the edit, the Unicode characters are replaced with the Discourse graphics. Is that a configurable feature?

I also noticed that the Discourse palette includes many that are not on Apple’s picker (and are therefore probably not actual Unicode), like the Money-Mouth face (:money_mouth_face:) and the Shaking face (:shaking_face:). Which probably explains why it’s not just sending Unicode sequences.

3 Likes