I think you've brought up a very legitimate concern. IPA and
other systems of phonetic transcription are a little different
from the norm for Unicode: in the general case, Unicode assumes
that the characters defined by the standard are abstract
*characters* and not *glyphs* (and even the notion glyph is
considered abstract such that two instances of a single glyph
don't need to have the same exact shape - see ISO/IEC 15285).
For IPA, however, the meaning of the character is very closely
associated with the glyph. For IPA purposes, the assumption is
that the character encoding is the same as a glyph encoding,
whereas a basic assumption of Unicode is that character
encoding is distinct from glyph encoding.
It may be that we could argue that we'd be better overall to
disunify U+0061 in this case. Another possible way of dealing
with this is to avoid any assumption that a font can serve a
wide variety of purposes. This is probably the best approach to
other issues as well: e.g. it is not the best solution to
assume that a single font can be used for Simplified Chinese,
Traditional Chinese, Japanese and Korean (there are ways to
deal with the fundamental variations in character shapes - the
Han disunification issue - in a single font, but there are also
preferences with regard to style of the typeface that are
different for each group). In this vein, we should probably
assume that presenting IPA data is best done using a font
specifically designed for this purpose. In such a font, U+0061
would always have the appropriate shape. This can present a
different issue, however: finding an IPA font and a Latin
script font for the body text of a document (assuming a
language that uses Latin script) such that the designs of the
two typefaces work well together.
Note that there is always an option of providing two different
glyphs for U+0061, and to have the rendering engines select the
correct glyph according to markup tags applied to the text.
This kind of technology has not yet arrived in any practical
way on many of our desktops, though.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT