Re: IPA a vowels

From: Markus Kuhn (Markus.Kuhn@cl.cam.ac.uk)
Date: Fri Sep 10 1999 - 10:01:52 EDT


Robert Brady wrote on 1999-09-10 12:09 UTC:
> I hope we see :
>
> LATIN SMALL LETTER A WITH HOOK,
> LATIN SMALL LETTER G WITH FUNNY THING BELOW,
> LATIN SMALL LETTER THETA,
> LATIN SMALL LETTER CHI,
> LATIN SMALL LETTER BETA,
>
> in Unicode 4. There are only 5 of these. There will not be any more, and
> without them, IPA support in Unicode is broken.

I remain a bit skeptical. You are focusing here on the freedom of the
font designer, who usually has a lot of freedom for the design of the
latin small letter a, but which is severely restricted as soon as the
font is also used to display IPA, because there the a needs to have
specific features. On the other hand, IPA was really intended as an
extension of the Latin script, and not as a script of its own, and many
African languages make heavy use of some selected IPA letters in their
orthography.

The other side of this issue is coding ambiguity. Say you have some
African language which uses an IPA-influenced orthography, will you use
LATTIN SMALL LETTER A or your new homoglyph LATIN SMALL LETTER A WITH
HOOK here?

I believe, the conclusion is that we should not think in terms of being
able to add IPA highly consistently to every font there is. Only a few
font styles are really useful for being extended into good IPA fonts, so
if you write dictionaries, linguistic textbooks, etc., you should make
sure you use one of these font styles. Do not expect that every Unicode
font will contain every Unicode character in high quality. Unicode
should be more seen as a scheme to encode characters, not as a
repertoire that from now on every font has to cover entirely.

Another good example of the style dependency of IPA are

  U+025F LATIN SMALL LETTER DOTLESS J WITH STROKE
  U+0284 LATIN SMALL LETTER DOTLESS J WITH STROKE AND HOOK

In spite of its name, the common glyph for U+025F seems to be a
reversed f. In the type of serif fonts used commonly with IPA,
the above two characters have two horizontal strokes. However, in
a sans serif font, the f/j has no stroke by itself, therefore
both characters in a sans serif font should only have a single
stroke for consistency with the font style. I wonder, whether
an IPA user would recognize U+0284 if the upper stroke were missing
in a sans serif IPA font.

In the end, font designers will continue to provide in their fonts only
those that they consider useful for the range of applications that they
have in mind for their fonts. Examples:

 - A German Fraktur font will typically come neither with IPA
   nor with Cyrillic or Georgina, because there never was a time where
   Cyrillic or Georgian languages were written in German Fraktur.

 - A proportional or italic font will typically not come with block
   drawing characters, because these make only sense for
   upright fixed-width fonts. Similarly, italic fonts will usually
   not have all mathematical operators and APL symbols, because
   these are traditionally only used in upright form.

 - An OCR-B font will typically not come with Arabic and Tibetian
   glyphs, because these are not part of the ISO standard for OCR-B.

Similarly, it is problematic to extend sans serif fonts and fonts with
the wrong shape of "a" to be IPA fonts, because there exists not a
widely recognized tradition for how to draft these characters. There is
nothing wrong with trying to do so, just don't mislead your customer
into believing that your font is highly suitable for printing IPA texts
then.

For every font style, there are Unicode characters that will not go well
with it. High-quality fonts will therefore always be Unicode subsets
only, and applications such as Web browsers who can prevent certain
characters from being used in certain style contexts will brutally
fall-back to other styles (e.g., pick math operators from the upright
font even inside italic text).

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT