From: Markus Scherer (firstname.lastname@example.org)
Date: Wed Jan 07 2009 - 13:53:40 CST
On Wed, Jan 7, 2009 at 10:54 AM, Roberts, Gary <Gary.Roberts@teradata.com>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
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
This archive was generated by hypermail 2.1.5 : Wed Jan 07 2009 - 13:56:17 CST