The conflicting needs of emoji

[Marius Spix]

There is actually a sequence of Unicode characters to clearly describe
a “Physics Teacher” without the downsides you have mentioned:

U+0050 U+0068 U+0079 U+0073 U+0069 U+0063 U+0073 U+0020 U+0054 U+0065
U+0061 U+0063 U+0068 U+0065 U+0072



Am Wed, 19 Oct 2022 17:58:10 -0400
schrieb "Mark E. Shoulson via Unicode" <unicode at corp.unicode.org>:

> On 10/14/22 18:28, Adib Behjat via Unicode wrote:
> > I second Mark’s sentiment and really like the suggestion. I also do 
> > think it would be wiser if this process was handled and managed by 
> > OSs/Apps versus Unicode.
> >
> > After reading Mark’s suggestion, I was reminded of a game where you 
> > combine basic/generic elements to create more complex elements
> > (e.g. https://littlealchemy.com/).
> >
> > For example, if someone wants to generate “Physics Teacher”, a user 
> > can type in their device:
> > 🧑‍🏫⚛️
> 
> Yes, this is essentially the "emoji kitchen" approach.  It has
> definite appeal and could work... and also distinct downsides: lack
> of control over what you actually mean, different people thinking of
> different formulæ, etc.  No scheme is perfect.  Those alchemy games
> are indeed a good example of this kind of thinking, but it has its
> ups and downs.
> 
> ~mark
> 
> >
> > And based on this combination, the OS/App can give the user the
> > option to generate a custom avatar to represent Physics Teacher.
> > With regards to rendering, tools like DALL-E (or other similar
> > diffusion models) can enable this capability. In addition, this
> > process will help encourage the introduction of more generic emoji
> > characters to help expand the foundational building blocks for
> > these tools.
> >
> >
> >> On Oct 14, 2022, at 2:43 PM, Mark E. Shoulson via Unicode 
> >> <unicode at corp.unicode.org> wrote:
> >>
> >> There are really two distinct animi(?) behind the push for 
> >> ever-more-detailed emoji, or rather, two animi for using emoji,
> >> and they pull in different directions, almost opposite.
> >>
> >> On one hand, people want an emoji that looks JUST like they want
> >> it to look. Maybe not even only for people!  But of course we see
> >> it most with people.  People want an emoji that looks like _they_
> >> look (do they really use it?  or do they just feel left out if it
> >> isn't available?  I'm not a heavy emoji-user, so I'm no judge, but
> >> I bet the second motivation is non-trivial as well.)  So the
> >> really do want "tall ectomorph female physics teacher with dark
> >> hair in Princess Leia buns, an eyebrow piercing (right), and a
> >> birthmark on the left side of the chin." This motivates the
> >> various suggestions of somehow encoding a teeny image and
> >> pretending it's somehow "plain text", or encoding a link to it or
> >> something.  I had what I thought were helpful ideas about the
> >> recent notions being floated at the last Unicode meeting I
> >> attended, and maybe they're even being thought about...  But
> >> although I've thought that maybe sending images like this was the
> >> best of the suggested solutions, it's still awful.
> >>
> >> The other problem is the other animus involved.  Because it isn't 
> >> just a picture that people want when they use emoji.  It isn't
> >> enough that there's a little picture of a person wearing a
> >> mortarboard hat or something, there's actual semantic information
> >> embedded in the encoded text as well.  It isn't just a picture,
> >> it's a codepoint(-sequence) that means something, a bit-sequence
> >> that _means_ "TEACHER." Just like U+0065 means something more than
> >> the ink used to draw it in whatever font. People want some snippet
> >> of "text" that not only looks like them, but also *means* them.
> >> Hence in my example above, expressing some of the various physical
> >> traits are one thing, and you can represent TEACHER with some
> >> cultural convention like a mortarboard hat (or THIEF with a mask),
> >> but how do you get across "PHYSICS teacher"?  Or a dozen other
> >> subjects, arbitrarily finely divided?
> >>
> >> When I think about it, I don't know that people would really be 
> >> satisfied with image-sticker emoji.  After all, not everyone has
> >> the skill to draw them (which is why we rely on emoji-font artists
> >> in the first place), or make them Just So, and I really do think
> >> that people would feel the lack of semantic meaning.  A lot of
> >> messaging services already let you include little graphics images,
> >> but I don't think the people using them feel this desire for new
> >> emoji any less.  How many homedrawn emoji do you really think will
> >> be made?  How many used more than twice?  How many used by more
> >> than one person?  How many will even be understood by the
> >> recipient?
> >>
> >> Asmus' point about comparing it to swapping out lego bits is 
> >> well-taken. There have long been these kind of "avatar engines"
> >> that let you swap around features to get something kind of like
> >> you (I remember one on the Wii way back when.) And maybe there is
> >> some reasonable limit to how much customization can be provided
> >> (though I'd bet anything we'd take forever agreeing on it.)  And
> >> even within specific limits like hair-style and hats, there'll
> >> always be one more that we're lacking, one more Mr Potato Head
> >> piece people will push for.
> >>
> >> (Actually, thinking about Asmus' line about "faces drawn on,"
> >> how's this for an idea, combining raster with standard? Instead of
> >> drawing some random picture yourself for an emoji, you have an
> >> image of, say, facial features that's to be projected onto a blank
> >> emoji-face, which can be any "standard" emoji or whatever. Could
> >> have other distinct ways of specifying headgear images, etc.  The
> >> renderer would be smart enough to scale or transform the image
> >> appropriately for different kinds of emoji with faces in different
> >> places and orientations etc. Probably a beast to implement, but
> >> I'm just floating ideas.  This one actually has signs of MAYBE
> >> bridging the gap between the two drives for emoji.)
> >>
> >> Perhaps the best "generalized emoji" implementation is something 
> >> along the lines of the Emoji Kitchen, where you can combine
> >> arbitrary emoji in arbitrary numbers and orders and the system
> >> does its level best to figure out SOME way for the resulting image
> >> to make sense. This gives you some genericness, and you can
> >> express all kinds of shades of meaning by combining enough emoji,
> >> but retains the semantic meaning of them as well.  Of course, it
> >> puts you at the mercy of how the system chooses to combine things,
> >> how good the designers are, etc etc.  You have no control over
> >> what really emerges at the end.  (I suppose if this ever became
> >> something widespread there would develop conventions for combining
> >> with a little more control (like Egyptian hieroglyph combiner
> >> marks??  Probably not, but with some semantic similarities.))
> >>
> >> Anyway.  Wanted to rant a bit on this "two desires" notion that I
> >> was thinking about since the last meeting.  I think it's important
> >> to remember the second one, which gets missed out on when people
> >> focus on controlling the picture just so (though it is what's
> >> behind the idea of using Wikidata codes.)  And the "images of
> >> features" notion occurred to me while typing this, and I think
> >> it's interesting.
> >>
> >> I'm not really trying to suggest answers here (though I did remark
> >> on some things favorably); this is more asking the questions.
> >> There's always going to be these two conflicting needs, and
> >> there'll always be people who want ever-finer distinctions in
> >> emoji, and there may simply not be any really good answers. Emoji
> >> probably never should have been part of Unicode (not "plain
> >> text"), but that ship sailed long ago, and even there it's not cut
> >> and dried (webdings? map symbols?)
> >>
> >> Thoughts?
> >>
> >> ~mark
> >>
> >>
> >> On 10/14/22 00:54, Asmus Freytag via Unicode wrote:
> >>> People that grew up on games are used to character editors that 
> >>> allow any avatar to be assembled from building blocks. Short of a 
> >>> common "avatar engine" shared across all platforms, a limited set
> >>> of emoji-legos isn't that unreasonable.
> >>>
> >>> We have skin tones, male/female, some limited use of color (black
> >>> + cat).
> >>>
> >>> Because of their small size, emoji faces would support more 
> >>> customization; it's hard to create a full character emoji on the 
> >>> level of detail of a game character. So you'd be limited to less 
> >>> detail than you can implement with real lego blocks. (And yes,
> >>> the ones for the heads of the little figure have removable hair
> >>> (and head gear). Plus a variety of of faces (pirate) painted on.
> >>>
> >>> If that can be done in the physical world, there's no reason a 
> >>> subset of that couldn't be supported in emoji rendering.
> >>>
> >>> People will intuitively sense that that should be possible and
> >>> thus the pressure to innovate in that direction won't stop.
> >>>
> >>> Just my $1/50.
> >>>
> >>> A./
> >>>
> >>> On 10/13/2022 4:38 PM, Mark E. Shoulson via Unicode wrote:
> >>>> Again, this way lieth madness.  People aren't satisfied with an 
> >>>> emoji for "female teacher with dark hair"; they want "TALL,
> >>>> THIN, female PHYSICS teacher with dark hair IN PRINCESS-LEIA
> >>>> BUNS AND A PIERCED EYEBROW (GOLD RING)." And if you give in on
> >>>> "welllllll, okay, we'll give in on the tall/short...," you're
> >>>> only encouraging them to beg for the rest. ("How about only a
> >>>> _little_ tall?  How about broad-shouldered? small-breasted?")
> >>>>
> >>>> (Though my opinion isn't actually quite what that sounds like:
> >>>> even I admit that there probably *are* things that are
> >>>> appropriate to give in on, and I know we all can argue all the
> >>>> day long about them.)
> >>>>
> >>>> ~mark
> >>>>
> >>>> On 10/13/22 09:22, William_J_G Overington via Unicode wrote:
> >>>>> Thank you for posting about this.
> >>>>>
> >>>>> Could one use variation selectors with this too, so as to have
> >>>>> a default style of glasses and various styles of glasses
> >>>>> available?
> >>>>>
> >>>>> Or would one need to have separate styles of glasses each
> >>>>> encoded separately?
> >>>>>
> >>>>> If both approaches are possible, which one would be better?
> >>>>>
> >>>>> If it is to be encoded, and I hope it will be, it would be good
> >>>>> to go for the lot all at once. Lots of styles as glasses are in
> >>>>> lots of styles.
> >>>>>
> >>>>> In my opinion it is no use just doing one and leaving the rest
> >>>>> for some future time as that is often a recipe for the rest
> >>>>> never getting done.
> >>>>>
> >>>>> If the lot is done as one grand forward leap then that is the
> >>>>> way to keep Unicode thriving.
> >>>>>
> >>>>> William Overington
> >>>>>
> >>>>> Thursday 13 October 2022
> >>>
> >>>
> >