I used the character ↔︎︎ (U+2194) in a blog post recently and once again got bit by the giant pawn problem. That’s my name for when a character intended to be rendered as text is surprisingly rendered as an emoji. I saw
when what I intended was
I ran into the same problem a while back in my post on modal logic and security. The page contained
when I intended
This example is more surprising because → (U+2192) is rendered as text while ↔︎ (U+2194) is rendered as an image. This seems capricious. Why are some symbols rendered as text while other closely-related symbols are not? The reason is that some symbols are interpreted as emoji and some are not. You can find a full list of text characters that might be hijacked as emoji here.
One way to fix this problem is to use the Unicode “variation selector” U+FE0E to tell browsers that you’d like your character interpreted as text. You can also use the variation selector U+FE0F if you really do want a character displayed as an emoji. See this post for details.
(I use U+FE0E several times in this post. Hopefully your browser or RSS reader is rendering it correctly. If it isn’t, please let me know.)
Update: This post looks terrible in the RSS reader on my phone because the reader ignores the variation selectors. See the comments for a screenshot. It renders as intended in my browser, desktop or mobile.
It’s not always convenient or even possible to use variation selectors, and in that case you can simply use different symbols.
Here are four Alternatives to ↔︎ (U+2194):
- ⟷ (U+27F7)
- ⇔ (U+21D4)
- ⟺ (U+27FA)
- ⇆ (U+21C6)
There is no risk of these characters being interpreted as emoji, and their intent may be clearer. In the two examples above, I used a double-headed arrow to mean two different things.
In the first example I wanted to convey that the Hodge operator takes the left side to the right and the right side to the left. Maybe ⇆ (U+21C6) would have been a better choice. In the second example, maybe it would have been clearer if I had used ⇒ (U+21D2) and ⇔ (U+21D4) rather than → (U+2192) and ↔︎ (U+2194).
Another math symbol that is unfortunately turned into an emoji is ↪︎ (U+21AA). In TeX this is \hookrightarrow. I used this symbol quite a bit in grad school to indicate that one space embeds in another. I don’t know of a good alternative to this one. You could use ⤷ (U+2937), though this looks kinda odd.
My RSS reader on my phone not only ignores all variation selectors, but it renders emoji as giant images.
I think the huge icons in feed readers (e.g. Feedly in Chrome desktop here) may be due to the feed generator? When I look at the view-source for the feed, I see img tags instead of the unicode entities.
My browser (Chromium on Linux) renders the page just fine, but I use The Old Reader as my RSS reader, and in the same browser the variation selector seems to be ignored when viewing the page through the RSS reader.
I’m trying to better understand UNICODE characters such as U+FE0E. I’m not finding descriptions of how the character modifies presentation or I’m misreading. How did you discover the effects of variant selector byte sequences, perhaps through experimentation?
References:
– https://unicode.org/charts//PDF/Unicode-3.2/U32-FE00.pdf
– https://util.unicode.org/UnicodeJsps/character.jsp?a=FE0E
– https://graphemica.com/blocks/variation-selectors
– https://en.wikipedia.org/wiki/Variation_Selectors_%28Unicode_block%29
This isn’t part of Unicode per se but how people implement it. Unicode makes U+FE0E and U+FEOF available, but someone (Google? Apple? W3C?) decided that FFOE means plain text and FFOF means emoji. I don’t know who made that decision, and I don’t even remember now how I learned about it.