Comment by mgdlbp | Hacker News Reader

Comment by mgdlbp | Hacker News Reader

Parent Full thread

Unicode already has a way to specify that emoji should be rendered black-and-white for consistency with surrounding text: affixing the combining character U+FE0E VARIATION SELECTOR-15 (examples[0]). Some touch keyboards have the text-style variations in the flyouts.

This only works on emoji for which a variation sequence is defined. Some emoji render the text presentation by default; you can choose the emoji presentation for those using U+FE0F VARIATION SELECTOR-16. Sequences also exist for ideographic variations like single- or double-storey 'a' and 'g', unified CJK, and miscellaneous ones such as serifs for certain mathematical characters.[1]

[0] https://en.wikipedia.org/wiki/Miscellaneous_Symbols_and_Pict...

[1] https://unicode.org/faq/vs.html

I find this tool handy for listing the Unicode characters in a string.[2]

[2] https://qaz.wtf/u/show.cgi?show=%F0%9F%8C%8D%EF%B8%8E

Edit: An easy way to add the variation selector without a method for Unicode input (though there's a registry hack for Windows to enable Unicode alt codes): put the emoji in an address bar, then add the URL-encoded variation selector,

  %EF%B8%8E

Just for clarification: the variation selector for selecting text presentation only applies to emoji that have a text presentation, which is a subset of all emoji: https://unicode.org/Public/UNIDATA/emoji/emoji-variation-seq...

For example, there is no text style "pizza" emoji.

This particular project is an attempt to provide a black and white emoji rendering for all emoji, which is distinct from the Unicode approach of allowing specific text / emoji stylizations for certain emoji.

Interestingly, SLICE OF PIZZA (and many other unlisted emojis) can render as text for me (on Windows 10). Did Microsoft implement them out-of-spec?

Here along with FIRE EXTINGUISHER, which doesn't: https://qaz.wtf/u/show.cgi?show=%F0%9F%8D%95%EF%B8%8E%F0%9F%...

That's Segoe UI Symbol: https://docs.microsoft.com/en-us/typography/font-list/segoe-.... The reason these exists is for backwards compatibility: fonts that bring their own colors is a weird thing that is brought from the future, so Microsoft has always these fallback fonts. Ironically, the biggest consumer of these is Google Chrome until they bothered to fix their browser to render color fonts (emoji fonts are very messy - Apple uses PNG-in-OTFs, Google uses a proprietary bitmap format, Adobe and Mozilla supported SVG-in-TTFs, and Microsoft having a custom vector format). Also, there are other contexts where color is a bad thing, so this set is used instead.

(Actually, Segoe UI Emoji (https://docs.microsoft.com/en-us/typography/font-list/segoe-...) does have also the fallback B&W emojis, but the proper way is to refer to Segoe UI Symbol first.)

> For example, there is no text style "pizza" emoji.

https://i.imgur.com/S101VQD.png

Stock in Windows 10. I'm not sure how, but so far, the ones that didn't work were zero-width-joined.

> Sequences also exist for ideographic variations like single- or double-storey 'a' and 'g', unified CJK, and miscellaneous ones such as serifs for certain mathematical characters.[1]

I couldn’t find the variations for a and g in the text file. Are you sure these are standardised variations?

They aren't! Good catch; I'd assumed from the example. Another slip-up: ideographic should modify unified CJK, not the Latin letters.

Variation sequences for double-storied 'a' and 'g' were proposed, as part of the only Unicode proposal with substantial Latin glyph variations,[1] to address the problem raised by the answer to the FAQ,

  Q: Can all glyph variations be represented with variation sequences?

…that there are separate codepoints for only the single-storied glyphs, meaning only fonts that assign the double-storied glyphs to the original ASCII codepoints can contrast the variations. The proposal went through two rounds of UTC,

- first as agendum C.4 of UTC 126 (http://unicode.org/L2/L2011/11015.htm),

- then rescheduled (https://www.unicode.org/cgi-bin/GetL2Ref.pl?126-A79)...

- as agendum C.21 of UTC 127 (https://unicode.org/L2/L2011/11115.htm),

- but ultimately wasn't acted upon (C.21.1 of https://unicode.org/L2/L2011/11116-pre.htm)

It did leave an extensive debate as precedent for what glyph variations are to be used for,[2] namely not localization as the proposal had largely intended. A shorter discussion in retrospective occurred when it was brought up again in 2018.[3]

[1] L2/10-280 / L2/11-059 (https://www.unicode.org/L2/L2011/11059-latin-cyr-var.pdf)

[2] https://unicode.org/mail-arch/unicode-ml/y2010-m08/thread.ht...

[3] https://www.unicode.org/mail-arch/unicode-ml/y2018-m07/threa...

Wow, many thanks for digging all of this out. It’s pretty cool that the Unicode proceedings are public.

[presented without commentary] my device displays each variation identically

Reply on news.ycombinator.com