Re: Emoji: chart updated with font glyph images

From: Markus Scherer (
Date: Wed Jan 07 2009 - 13:53:40 CST

  • Next message: Mark Davis: "Re: Emoji: chart updated with font glyph images"

    On Wed, Jan 7, 2009 at 10:54 AM, Roberts, Gary <>wrote:

    > I don't like colours in character names unless I understand the reasoning
    > (for example, I have no issues with RED DRAGON). The only example I caught
    > that I do not understand is GREEN EARTH. Perhaps EARTH VIEWED FROM SPACE.

    Rick also commented on this name. We will rename e-039 GREEN EARTH to just

    > The font looks pixel based (not surprising given the history of the encoded
    > symbols). I think it needs to be line based. I particularly object to pixel
    > based shading being used.

    The font is an outline font, but the chart uses font images (.png files)
    generated from the font's glyphs, to avoid having everyone download the

    I would prefer the font to look more symbol like, and less picture like.
    > There is too much detail for me in this font. For example, I prefer the
    > DoCoMo #172 glyph to the proposed e-008 glyph, although I think I would
    > prefer not to have a black background (Maybe a white cresent moon with stars
    > similar to the one in your porposed glyph, and no buildiings.). I understand
    > that what I am asking for would be a lot of work, but I figure it doesn't
    > hurt to ask.

    I will note it as an issue. Personally, I don't care much about the
    particular shapes as long as they are representative. The glyphs we have
    were designed by someone (or some team) at Apple.

    > Not sure about all these hearts, particularly distinctions between e-B13 -
    > e-B16 Is there any semantics associated with the colour differences? Given
    > the DoCoMo 'unification' of these, this appears to be a candidate for
    > variant selectors.

    Both KDDI and SoftBank distinguish these, and we apply the source separation

    Source seperation rule:
    > I think we should use variant selectors instead of encoding duplicate
    > characters.

    That's still source separation, it just pushes the encoding of such
    characters from separate code points to separate registered variation
    sequences, which is a more complicated mechanism and not usually done for
    Unicode symbols.

    Best regards,

    This archive was generated by hypermail 2.1.5 : Wed Jan 07 2009 - 13:56:17 CST