From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Sun Jan 04 2009 - 19:26:19 CST
On 1/4/2009 11:50 AM, Jukka K. Korpela wrote:
> (Continuing my previous message, which was sent prematurely.)
>
> Karl Pentzlin wrote:
>
>> The printed Unicode 5.0 edition says on p.564 within section 17.1,
>> below the header "Images in the Code Charts and Character Lists":
>> "Each character in these code charts is shown with a representative
>> glyph. A representative glyph is not a prescriptive form of the
>> character, but rather one that enables recognition of the intended
>> character to a knowledgeable user and facilitates lookup of the
>> character in the code charts."
>
> I think this tries to say that “representative” means roughly the same
> as “typical”, implying some generality in the sense that there are no
> special features, as some fonts have for some characters. I don’t
> think it really says much more than that.
+1
With the proviso, that if the glyph in the charts is not a
meta-notation, the choice of that glyph is the official "representative"
glyph, as opposed to all other possible (more or less common and/or
acceptable) glyph variants.
>
>> Are the following statements true?
>>
>> 1. The representative glyph of U+0323 COMBINING DOT BELOW is a dotted
>> ring on the baseline with a dot beneath of it.
>
> No, I don’t think it means to say that. If the standard does not
> describe this, it should. The dotted ring is surely not part of the
> representative glyph, or any reasonable glyph. Rather, it indicates
> the placement of a base character to show the typical position of the
> mark.
This is a generic feature of the representation of combining characters
and is explained in chapter 17.
>
>> 2. The representative glyph of U+0020 SPACE is a Latin letter pair
>> "SP" surrounded by a dotted square.
>
> No, surely not. This too should of course be explained, even though it
> is more or less evident.
Same.
>
>> 3. Representative glyphs are always printable using black color on
>> white background, without using gray shades and/or other colors.
>
> I don’t think the standard says or means to say that, but it would be
> a natural idea—though the question would arise why one says that.
>
>> 4. The representative glyph of a character is not necessarily a valid
>> visual representation of the character itself to be used within its
>> plain text use.
>
> That would not make sense, would it?
+1
Item 4 is confusion meta-representation with a "representative glyph".
>
>> This especially applies to control codes and space characters which
>> have no glyphic representation by nature,
>
> For this reason, it should be explained which entries in the charts
> are not representable glyphs but metanotations of a kind.
This is clear from reading the rest of chapter 17: Controls, format
characters, and Spaces have dashed boxes, combining marks have dotted
circles (one character has both, by the way) and finally, there is
metanotation for code points as well: non-characters are shown as black
cells, unassigned as hashed, etc.
>
>> but also for some special
>> cases where the glyphic representation of the character cannot be
>> expressed unambiguously within its block by a glyph printable black
>> on white, e.g. for U+2011 NON_BREAKING HYPHEN or U+2591 LIGHT SHADE
>> (the latter one being a gray shade by nature and by its correct
>> naming).
>
> For U+2011, the entry in the chart is surely not a representative
> glyph but something that contains it. For U+2591, I would say that the
> glyph is acceptable. Whether it is representative is debatable, so
> maybe the description of “representative” should be augmented with a
> note about restricting to black and white rendering, which is not
> always optimal for all characters.
For U+2591, the choice of representative glyph reflects how this is
documented in the context of the source character set(s). A rendering
with a smooth grey level would be a glyph variant.
>
>> 5. The representative glyph does not denote the character
>> unambiguously (e.g. U+0042/U+0392/U+0412).
>
> That must be true since characters may well have identical rendering
> even in typical circumstances.
Correct. There are some character pairs for which typical rendering is
identical (if they appear in the same font). Therefore, the choice of
representative glyph reflects that aspect. Some Arabic characters are
the same in some of their positional variants, but not others. In that
case, it may make sense to not show the (typical) isolated form for
both, but a different positional form for one of them, to make more
obvious what's intended.
>
>> 6. The reference glyph of the emoji e-B16 (purple heart) may be a
>> black and white striped heart
>
> I guess this is the point you are getting at. It looks rather odd to
> me that a character could have color (still less multicolor features)
> as part of its identity, but this seems to be the way Unicode is
> taking. It may open entire new worlds, or cans of worms, or something
> else.
>
> To me, something that _needs_ to be in a particular color is an image
> by nature. It can be used inline, inside text, as any image can, but
> not in plain text and it isn’t a character. There is no deep reason
> why colors could not be part of character identity. Until now, it has
> just seemed to be more pragmatic and more useful to treat color
> indications as belonging to other “protocol levels”. I wonder if there
> is a deep reason, or a good reason, or even a serious reason to change
> this just like that.
If a black and white fallback makes sense and can be agreed upon, I
would think it's natural to use it as representative glyph, but I'd
expect an annotation in that case.
>
> 7. If someone provides evidence for a real "STRIPED HEART" symbol,
>> he may propose it, using the same representative glyph as for the
>> purple heart.
>
> Well, propositions can always be made, and some of them may get
> rejected at first glance. :-)
>
+1.
(at the minimum, the proposal would have to demonstrate that this new
character is being used *in contrast* to the existing character, and is
not merely a consequence of using a black-and-white fallback for the
original character).
A./
This archive was generated by hypermail 2.1.5 : Sun Jan 04 2009 - 19:29:01 CST