Page MenuHomePhabricator

Maybe render all text with IMPRESSIVE illuminated drop caps
Open, WishlistPublic

Assigned To
None
Authored By
epriestley
Feb 5 2018, 6:23 PM
Referenced Files
F5412981: old_london0.png
Feb 5 2018, 6:23 PM
F5412984: Screen Shot 2018-02-05 at 10.23.02 AM.png
Feb 5 2018, 6:23 PM
Tokens
"Manufacturing Defect?" token, awarded by avivey.

Description

Some advantages:

  • Reasonable way to make huge emoji render.

Disadvantages:

  • To get okay CSS behavior this has to be on the <p> tag I think, not a <span>.
  • No good default font? We want something like this, but none of the default macOS fonts are even close, at least:

old_london0.png (71ร—431 px, 2 KB)

  • Kind of a lot of layout issues.
  • Some users will want "normal text" back and "complain" about this.

Screen Shot 2018-02-05 at 10.23.02 AM.png (1ร—2 px, 332 KB)

Revisions and Commits

Related Objects

Event Timeline

epriestley triaged this task as Wishlist priority.Feb 5 2018, 6:23 PM
epriestley created this task.
epriestley renamed this task from Maybe render all text with illuminated drop caps to Maybe render all text with IMPRESSIVE illuminated drop caps.Feb 5 2018, 6:23 PM

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.)