Re: U+2018 is not RIGHT HIGH 6

>> Yes. If necessary, an OpenType font could provide different glyphs
>> for different languages to provide optimally looking shapes.
>
> a) So code point-to-glyph mapping in a font is not one-to-one?

With OpenType fonts, this is correct.

> b) Then the, say, "German glyph" for U+201C (“) will look like
> U+201E („) (and thus be LEFT and "opening") and the one for
> U+201D (”) will look like U+201C (“)? and like U+00AB («) and
> U+00BB (») for French?

This is a possibility, yes. However, you normally won't find fonts
which do that.

> c) Why have U+201E, U+00AB and U+00BB been encoded then?

There are at least two reasons:

 1) Existing major standards have them already included, and Unicode
    maintains a roundtrip compatibility to them.

 2) There might be different quotation characters within a document,
    meaning different things. In other words, there are documents
    where the distinction between various quotation marks is more than
    a glyph variant.

> d) Is U+201F (‟) considered a mistake then? It is only about looks,
> not about meaning like a RIGHT HIGH 6 Q... would be.

See my second argument above.

> e) How does the font know which glyph to choose for a given, say,
> UTF-8 byte sequence? Do we get back to "charset" selection then?

In many cases, plain UTF-8 text doesn't transport enough meta
information to be rendered correctly. It is the job of the user's
environment, or the heuristics built into the rendering engine, or
explicit users settings or document tagging (script, language, etc.)
to provide this information.

> f) Should a code point not encode meaning and thus a "left opening"
> mark never be required to be abused as a "right closing" one?

This is not how Unicode works. You can find the fine details in the
standard.

Whether a certain character is `opening' or `closing' is a meta
information, usually depending on the language (or the country, or the
writing direction, or...), to be provided by a higher level.

    Werner
Received on Fri Apr 27 2012 - 11:03:31 CDT