I've been wanting to make a "giant emoji" task since emoji were added but was too afraid...

Yeah, the only reason I pursued this was for giant emoji. I was just going to do {huge 🐱} or something first, but then I figured {drop-cap 🐱} was a little more defensible as a general feature while still solving the huge emoji problem.

Maybe {huge 🍦} is really the right way forward here, though.

Currently there's no way to make an increasingly larger parade of dogs

=====:dog2:=====
====:dog2:====
===:dog2:===
==:dog2:== 
=:dog2:=

🐕

🐕

🐕

🐕

🐕

It's a real tragedy. The biggest header is definitely unacceptable for huge emoji.

Some other possibilities:

• A {style ...} rule, like {style 🐶 size=30, effect=bounce}.
• Let {icon 🍰} evaluate as 🍰, then add size, so {icon 🍑 size=72, spin} works.

Maybe extending {icon ...} is actually reasonable? deserves to be size 72, too.

Would you want to include the use case of making specific letters/words of inline text larger/smaller/bouncier? I like the idea of {style ...} though it is awfully similar to {icon ...}

As it turns out, I wrote a bit of {icon ... size=72} yesterday but ran into a related issue: it's hard for us to tell if the X in {icon X} is a single character or not.

I don't think whole words should work -- if {icon cromulent} works, this should just be {style ...}, since "icon" doesn't make any sense anymore and it would selectively be impossible to stylize a couple hundred common words which happen to be icon names (like paw, cloud, cog, etc).

But if {icon A} works, that seems okay. However, it's hard to test if "A" is a single letter or not because "💁" is one codepoint but "💁🏼" is two: "INFORMATION DESK PERSON + EMOJI MODIFIER FITZPATRICK TYPE-4".

We have phutil_utf8v_combined() but it currently doesn't combine the Fitzpatrick modifiers and I'm not sure if this modifier block counts as combining characters. It probably does, or should for our purposes, but I didn't want to just change the definition casually so I can have a big picture of a dog.

I also know this problem to be hard in the general case because of sequences like <WOMAN> <DARK SKIN TONE> <ZWJ> <HEART> <ZWJ> <KISS> <ZWJ> <WOMAN> <MEDIUM DARK SKIN TONE> which (ideally) renders as a single glyph, although, per D17244, I believe <JUDGE> <WOMAN> <LIGHT SKIN TONE> <ZWJ> <HEART> <ZWJ> <KISS> <ZWJ> <CAT> <ZWJ> <DARK SKIN TONE> <ZWJ> <COMPUTER> ("Light-Skinned Female Judge Kissing Dark-Skinned Hacker Cat") isn't valid. We could probably still combine it for the purposes of {icon ...} but that will break the sequence for phutil_utf8_console_strlen().

Unfortunately, that means the current implementation in my development environment is kind of racist, so I want to figure this out one way or the other before trying to ship anything.

(I'd also like to normalize all glyphs that can be modified by skin tone in a smarter way since the kind of default implementation we ended up with is really clunky.)