Re: Playing card suit symbols and colors

From: Kenneth Whistler (
Date: Mon Jan 19 2009 - 19:40:02 CST

  • Next message: Werner LEMBERG: "Re: Ossetian letter missing in Unicode?"

    > Am Samstag, 17. Januar 2009 um 08:42 schrieb Asmus Freytag
    > (Re: Revised Comments on some emoji symbols e-000 ... e-521,
    > regarding inherent colors of emoji symbols, on the Unicode and Emoji
    > lists):
    > AF> ... this is like the card suits in the 26xx block. They are called
    > AF> black and white, even though they are obviously intended as black and
    > AF> red. You would overturn a precedent ...

    And Karl Pentzlin responded:

    > The card suit symbols, as they are encoded, are not suited as
    > precedence for handling inherently or explicitly colored characters.

    Well, the truth is somewhere in between, I think. Asmus is
    correct about the naming conventions for this set of symbols.
    But it is a little off to suggest that "red" in this case
    is associated with outline symbols; for the card suits the
    red color clearly is associated with hearts and diamonds,
    whether or not one is using a solid or outline symbol for

    > If these symbols were encoded today, there probably were four symbols

    > according to the four suits, simply named
    > *U+xxx1 CARD SUIT SPADE
    > *U+xxx2 CARD SUIT HEART
    > *U+xxx4 CARD SUIT CLUB
    > without specific reference to colors, as spade and club are implicitly
    > black, while heart and diamond are implicitly red, and there are no
    > color variants which would qualify as distinct characters.
    > However, the suit symbols are not encoded due to a requirement to have
    > card suit symbols in Unicode. These symbols are inherited from another
    > encoding industry standard, presumably the IBM code page 437 ubiquitous
    > during the DOS area, which contains the four card suit symbols as filled
    > variants


    > (as color was at the time expressed by character cell
    > attributes independent from the character itself).

    A fact which is still relevant, however, because while we have
    moved past character cell attributes, color is *still* carried
    by higher-level protocols, independent of the characters

    > These characters all were "black" in the Unicode sense.


    > For whatever reasons this characters were doubled at the time they
    > were introduced into Unicode (version 1.1 according to the DerivedAge
    > table). In the first sequence U+2660...U+2663, the "red" ones were
    > included as hollow characters ("white" in Unicode terminology) while
    > the "black" ones were left filled. In the second sequence
    > U+2664...U+2667, the filled variants (i.e. these presumably taken from
    > the original source) were added, and hollow variants were added for the
    > "black" ones without apparent reason (symmetry?).

    Nope. Time to go back to the *real* character history here,
    instead of just making it up as we go along. ;-)

    The proximate source of these symbols in Unicode is the Xerox
    Character Code Standard, and more specifically the June 1990
    edition of that standard.

    The *first* set of these is from "Character Set 357" in that
    standard, to wit (I'm quoting the descriptions there):

    357/313 Solid or black spades = spade suit symbol
            Also: Dingbat (spades (playing card) solid);
            <AMS, spadesuit>; <ITC, 392>
    357/314 Open hearts = heart suit symbol
            Also: Dingbat (hearts (playing card) outline);
            <AMS, heartsuit>; <ITC, 397>
    357/315 Open or white diamonds = diamond suit symbol
            Also: Dingbat (diamonds (playing card) outline);
            <AMS, diamondsuit>; <ITC, 398>
    357/316 Solid or black clubs = club suit symbol
            Also: Dingbat (clubs (playing card) solid);
            <AMS, clubsuit>; <ITC, 395>
    the *second* set of these is from "Character Set 356" in that
    standard, to wit:

    356/313 Open (357 | 313) spades
            Also: Dingbat (spades (playing card) outline);
            <ITC, 396>
    356/314 Solid (357 | 314) hearts
            Also: Dingbat (hearts (playing card) solid);
            <ITC, 393>
    356/315 Solid (357 | 315) diamonds
            Also: Dingbat (diamonds (playing card) solid);
            <ITC, 394>
    356/316 Open (357 | 316) clubs
            Also: Dingbat (clubs (playing card) outline);
            <ITC, 399>
    The complete set of eight were well-defined *prior* to
    the completion of Unicode 1.0. They were incorporated into
    Unicode at that point *already* as compatibility characters,
    to ensure coverage of the relevant sets of symbols from

    And if you examine the Xerox documentation, they weren't
    in that standard for haphazard reasons, either. The first
    set covered the then preexisting AMS entities *and*
    the ITC Dingbats. The second set completed the coverage
    for the ITC Dingbats, which contained both a solid set
    for all four suits and an outline set for all four suits.
    Not just the ITC Zapf Dingbats series 100, by the way (which
    just includes the four solid symbols), but the entire ITC set.

    The Xerox documentation also makes it clear where the
    Unicode conventions for black (= solid) and white (= open,
    outline) symbols comes from.

    Now it's true that for best use for card suit symbols
    in text, people should probably pick the black (solid)
    set: 2660/2663/2665/2666, in part because those are
    best represented in fonts, and because even in non-color
    representations, the more common convention is to
    use solid symbols. See, e.g.:

    which is fairly typical.

    On the other hand, if you need to map to the AMS entity
    set, then you need, instead: 2660/2661/2662/2663. (See
    the Xerox documentation.)

    And in those unusual cases where someone may choose to
    represent card suits with outline symbols, then you could
    choose all the "white" symbols: 2661/2662/2664/2667.

    There is no inherent connection between the character
    encoding per se and the conventional coloring of the card
    suits per se. *If* you have access to color via a higher-level
    protocol, then you can choose the all solid set and color
    the hearts and diamonds red. If not, then you can go with
    any of the three conventions I just mentioned, and go just
    with black or black&white glyphs.

    Here's an example that uses solid symbols for the clubs
    and spades and outline symbols for the diamonds and hearts:

    > Thus, the card suit symbols are no precedence for including any symbols
    > today, except anybody would propose some symbols to include as a filled
    > ("black") and additionally as a hollow ("white") variant, e.g. encoding
    > emoji e+04F as two characters BLACK CHERRIES and WHITE CHERRIES.

    The details of the card suit symbols don't serve as precedents
    for other sets of symbols, I agree, in part because of the
    complicated history of the use of both solid and outline symbols
    for them -- *regardless* of color. The precedent that *does*
    apply for game symbols, in particular, is that when a set
    of game symbols involves a systematic bi-color distinction,
    then those symbols get mapped onto black and white symbol
    distinctions for characters in Unicode, regardless of whether
    the actual game counters in question are black and white,
    or black and red (the most common choices of contrasts).

    > A valid precedence for naming colored characters is (as I wrote in my
    > original mail on the Unicode and Emoji lists) U+2591...U+2593 which are
    > correctly named by their shade without causing any problems.
    > Thus, it will be correct to name emoji e+051 RED APPLE and e+05B GREEN
    > APPLE, as these characters are symbols for red apple and green apple.

    This *does* cause a problem, however. As naming such characters
    by such colors is an over-precise description of glyphs,
    and because it sets expectations for the display of such
    characters which cannot be met by Unicode plain text.

    Furthermore, the encoding of e+051 is not, in my opinion,
    a "symbol for red apple". Instead, this needs to be:

       a compatibility character for representing a Japanese emoji
       symbol which is displayed with a pictograph for an apple
       (with a red color on Japanese phones)

    Likewise e+05B is not a "symbol for green apple". Instead it needs
    to be:

       a compatibility character for representing a Japanese emoji
       symbol which is displayed with a pictograph for an apple
       (with a red color on Japanese phones)
    If everybody insists, instead, on abstracting these out as
    if they were a universal symbol *for* a red apple and
    *for* a green apple, then this whole discussion will continue
    to rathole endlessly on issues of philosophical appropriateness of
    dividing up the world of objects arbitrarily and representing
    them by symbolic characters [why not "symbol for golden apple"
    or "symbol for still green apple of variety that would be
    red when ripe" or "symbol for Braeburn apple"?]:

    > This does not imply to introduce any new properties or encoding
    > principles into Unicode.

    I disagree. It veers too far into the generic field of symbology
    and signs, which Unicode is not about. Unicode is about
    encoding characters for conventional visual symbolic depictions
    used in text. Example:

    U+2668 HOT SPRINGS

    is *not* a symbol of the geological concept of a hot spring,
    nor is it a picture of a hot spring. Instead is a character
    representation of a common graphic symbol seen used on maps
    and in tourist guides to convey to tourists the presence
    of a hot spring.

    > Any scheme to map real colors onto other terms, however, does
    > introduce a new encoding principle.

    In general I agree with that, which is why I have objected to
    using arbitrary combinations of black and white stripes and
    patterns to map to sets of glyphs distinguished by color on
    the Japanese phones. Far better to simply encode a set of
    compatibility characters with arbitrary variant names and
    be done with it for this particular set.


    > Doing such without any compelling reason and without having reached a
    > broad consensus within a public discussion participated by all relevant
    > bodies is strongly opposed.
    > - Karl Pentzlin

    This archive was generated by hypermail 2.1.5 : Mon Jan 19 2009 - 19:43:06 CST