From: Kenneth Whistler (kenw@sybase.com)
Date: Mon Jan 19 2009 - 19:40:02 CST
> 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
them.
>
> If these symbols were encoded today, there probably were four symbols
^^^^^^^^
Nope.
> according to the four suits, simply named
> *U+xxx1 CARD SUIT SPADE
> *U+xxx2 CARD SUIT HEART
> *U+xxx3 CARD SUIT DIAMOND
> *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
Nope.
> (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
themselves.
>
> These characters all were "black" in the Unicode sense.
Nope.
>
> 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
XCCS.
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.:
http://www.monmouth.com/~colonel/bridge/scoring.pdf
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:
http://books.google.com/books?id=yu27LzAVhYQC&printsec=frontcover
> 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"?]:
http://www.tomsonbuxton.co.uk/images/products/apple-2.jpg
> 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.
--Ken
> 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
