Re: font-family: IPA

On Mon, 10 May 2004, Chris Lilley wrote:

> - - the correct descriptor is clearly
> unicode-range.

Has that descriptor been actually implemented? I'm afraid its use would be
much more awkward than it might seem on the surface.

> IPA extensions is the 0250 block (0250 to 02AF)

Yes, but that's just the IPA _extensions_, which is probably the less
problematic part. The main problem is that the unification process
identified certain IPA characters with Latin letters in the Basic Latin
and Latin Supplement 1 blocks. There might be other problems as well, with
combining diacritics.

For example, the Latin letter "a" has two essentially different glyph
shapes, and the difference is usually just stylistic variation. But in the
IPA extensions block, there is one of those shapes classified as a
separate character. The problem is that IPA also uses the normal "a",
which may take either of the shapes, depending on font. This means that if
you use IPA without suggesting font-family at all, it is quite possible
that a browser picks up glyphs for the characters from different fonts so
that they have the same shape. This would remove an essential
distinction, indicating phonetic difference, defeating the very idea of
IPA. Similar things may happen when a style sheet is used, either because
the fonts suggested have different characteristics, or because the browser
needs to use glyphs from other fonts (including the browser's default
font).

Thus, CSS is not the right tool for the job. It's about presentational
suggestions only, designed to be overridable, and the problem is about
_making sure_ that a difference exists.

The best that an author can do at present is probably something like
  .ipa { font-family: Arial Unicode MS !important; }
perhaps adding some other font alternative(s), if some font is known to
contain all the characters needed in the IPA strings in the document.

I have mixed feelings about the proposed addition of a new generic font
family. In the long term, it might help a bit, if implemented. But it
would address the problem at the level of presentational suggestions
rather than at the level of character identity and writing systems.
IPA is first and foremost a writing system (a script) of its own,
so the logical approach would be based on a logical markup attribute
indicating this and some minimal browser support to it, rather than casual
class attributes and mere font face suggestions.

> so describing a font as an IPA font is a case of
>
> @font-face {
>  unicode-range: 25?;
>  font-family: WhateverIPA;
>  font-src: url(http://example.org/fonts/ipa/Whatever.svg) format(svg)
>  }

Such a requirement is neither sufficient nor necessary for being a useful
font for presenting IPA strings. Other characters are needed as well, and
on the other hand few documents need the full IPA repertoire.

> IH> Don't most "Unicode complete" fonts like Lucida Unicode and Arial Unicode
> IH> contain glyphs in that block?
>
> Yes, but the converse is not true.

I don't think there are any Unicode complete fonts, partly because Unicode
is a moving target. For example, Lucida Sans Unicode and Arial Unicode MS
(which is probably what you meant) do _not_ contain all
characters in the IPA extensions block; see the test page at
http://www.alanwood.net/unicode/ipa_extensions.html
and look at characters U+02A9 through U+02AF at the end.
(Moreover, containing just all the characters with a code position is far
from sufficient for presenting IPA strings. The browser needs to be
able to combine multiple diacritic marks with different base characters in
a sophisticated way - and a font could help here a little if it contains
some of the common combinations as precomposed glyphs.)

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Monday, 10 May 2004 02:06:31 UTC