Is this project open to new ZWJ sequences?

[sethwoodworth]

There have been numerous requests for a dumpster fire emoji, made by combining 🗑️ +ZWJ+ 🔥. If I offered a PR to implement this ZWJ sequence in Twemoji, would the repo maintainers be open to accepting it (pending PR review of course).

[OlivierJaquemet]

That would be really nice to support the ninja cat too!🐱‍👤 == 🐱 + ZWJ + 👤
😊

[polarathene]

If it's not an official emoji in the unicode spec, then it's not going to be something anyone without twemoji could see. While you might choose to use it in an embedded fashion such as via webfont to ensure it is available, it might be misleading to those less familiar with what official emoji are that do not do such, or try to copy/paste to send to someone else and get confused.

Does twemoji support any unofficial emoji already?

https://home.unicode.org/emoji/

That would be really nice to support the ninja cat too!

That's a good example of what I'm talking about. That's an unofficial emoji Microsoft created, and only they appear to support it: https://emojipedia.org/ninja-cat/

I'd rather neither be supported unless they become part of a new official release of emoji, I've just been dealing with rendering issues with emoji. Seeing tofu(those blank/empty vertical rectangles and the like) substituting missing glyphs/emoji (or the other kind, which is the decomposed version of multiple emoji) is not an enjoyable experience :) (even Facebook and Github tend to convert emoji into images for presentation).

[OlivierJaquemet]

Thanks @polarathene for this explanation.
Given this information, It is completely understandable that twemoji would not be updated to support unofficial emoji unless it comes completely widespread.

[Crissov]

There are several popular emoji sequences that are not recognized by Unicode and do not contain a ZWJ. 🆗🆒, 🗑️🔥 and 🐂💩 are specific to English, but others are more international, e. g. 👉👌 and 🤜🤛 or 🚗💨 and 🐘💨. Unicode originally anticipated that many more emojis would be used as markers after base emojis as the, were derived from symbolic conventions found in mangas and comic, e. g. 💔💤💢💣💥💦💨💫💬🗯️💭✨⚡❄️🔥💧.

Or would be perfectly fine to offer specialized graphics for all of those, but the maintainers have previously expressed their disinterest in this.

[polarathene]

but the maintainers have previously expressed their disinterest in this.

For good reasons. Even without such there was confusion for a user on platforms that use the Twemoji JS library to replace emoji with image elements in HTML, they thought that support for both Variation Selectors was in place, but it was really only for VS16(still not confirmed as I could not verify in codepen).

That seems to be due to looking up this official document for matches to detect emoji. Without resources like emojipedia, as a user that can be very confusing when the emoji deviate from expected behaviour.

I can understand why Github/Facebook/Twitter and the like would replace emoji with images, but it's not always obvious what is going on. Rarely are the fonts (when not using images in HTML) supporting both text and emoji presentations(for those that support it), but it's not uncommon for a user to know that multiple emoji fonts via fallback can be used, or how they're prioritized. Firefox bundles Twemoji as a browser emoji font(configurable in "about:config"). Other apps enforce their own choice of emoji as well(understandable for communication focused apps, to avoid confusion by potentially seeing different/broken rendering).

Yes, some emoji do combine others together to form one like a ligature without a ZWJ sequence. This can also cause problems though, just look at this one. Nothing wrong on the users system or their browser rendering it, but the developer themself had input the victory hand emoji(with it's VS16 codepoint for colour) beside a skin tone modifier emoji(which behaves in a special way during input, binding to whatever is left of it). That VS16 isn't meant to be used with the skin tone variants though and thus causes breakage with the expected rendering(if you copy/paste each one individually into Chrome, they'd compose automatically, but not in Firefox). The wastebucket emoji is one of those that uses VS16 for colour/emoji presentation(which presently causes some rendering issues in Firefox under certain circumstances, but that's being fixed).

Lets not opt towards more problems please. Especially since this font is packaged for some linux distros(not sure, but Fedora might make use of it), and Firefox bundles a version that presumably is kept in sync.

---

If you want official support, please ask for such via the correct official channel I linked to earlier. Then if approved, Twemoji and others will all naturally adopt it and everyone wins. Last thing you want is an unofficial font specific implementation, and then an official one coming out that has a different codepoint representation.

If you really want them without official support, I'd suggest modifying the font to include some additional ligatures for your personal use(or embedded webfont, however you plan to use it).