Re: font-family: IPA

On Monday, May 10, 2004, 7:39:55 AM, Jukka wrote:


JKK> On Mon, 10 May 2004, Chris Lilley wrote:

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

JKK> Has that descriptor been actually implemented?

In the absence of a CSS2 test suite I can't give a definitive answer
to that.

JKK> I'm afraid its use would be
JKK> much more awkward than it might seem on the surface.

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

JKK> Yes, but that's just the IPA _extensions_, which is probably the less
JKK> problematic part.

But it suffices to identify an IPA font, which must have at least some
coverage in that block.

JKK> The main problem is that the unification process identified
JKK> certain IPA characters with Latin letters in the Basic Latin and
JKK> Latin Supplement 1 blocks. There might be other problems as well,
JKK> with combining diacritics.

JKK> For example, the Latin letter "a" has two essentially different
JKK> glyph shapes, and the difference is usually just stylistic
JKK> variation. But in the IPA extensions block, there is one of those
JKK> shapes classified as a separate character. The problem is that
JKK> IPA also uses the normal "a", which may take either of the
JKK> shapes, depending on font. This means that if you use IPA without
JKK> suggesting font-family at all, it is quite possible that a
JKK> browser picks up glyphs for the characters from different fonts
JKK> so that they have the same shape.

Thanks, that wasn't clear before and is crucial to your argument.

JKK> This would remove an essential distinction, indicating phonetic
JKK> difference, defeating the very idea of IPA. Similar things may
JKK> happen when a style sheet is used, either because the fonts
JKK> suggested have different characteristics, or because the browser
JKK> needs to use glyphs from other fonts (including the browser's
JKK> default font).

Ok so its another case where you want to say "put all this in this
font; if you can't,  put it all in this other font" and so on.

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

OK, but in that case you should take it up with the Unicode consortium
rather than this list. And Unicode will likely tell you that they are
a character registry not a glyph registry.

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

Yes.

JKK> I have mixed feelings about the proposed addition of a new generic font
JKK> family. In the long term, it might help a bit, if implemented.

It seems the wrong way to approach the problem, to me.

JKK> But it would address the problem at the level of presentational
JKK> suggestions rather than at the level of character identity and
JKK> writing systems. IPA is first and foremost a writing system (a
JKK> script) of its own, so the logical approach would be based on a
JKK> logical markup attribute indicating this and some minimal browser
JKK> support to it, rather than casual class attributes and mere font
JKK> face suggestions.

Does it count as a language? Would xml:lang apply? if so, the :lang
selector could be used more interoperably than a random class name.

>> 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)
>>  }

JKK> Such a requirement is neither sufficient nor necessary for being a useful
JKK> font for presenting IPA strings. Other characters are needed as well,


That descriptor does not say 'this font only has coverage in
the given range' it says 'this font includes coverage in this range'.

JKK> and
JKK> 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.

JKK> I don't think there are any Unicode complete fonts, partly because Unicode
JKK> is a moving target.

There are complete fonts for Unicode 2 and for Unicode 3.2. But I was
referring to a class of fonts that go for very broad coverage; IA
fonts are typically not in that class.

JKK> For example, Lucida Sans Unicode and Arial Unicode MS
JKK> (which is probably what you meant)

(Not sure how you draw that conclusion)

JKK> do _not_ contain all
JKK> characters in the IPA extensions block; see the test page at
JKK> http://www.alanwood.net/unicode/ipa_extensions.html
JKK> and look at characters U+02A9 through U+02AF at the end.

They displayed fine for me, but then I have SILDoulosUnicodeIPA
installed.

JKK> (Moreover, containing just all the characters with a code position is far
JKK> from sufficient for presenting IPA strings. The browser needs to be
JKK> able to combine multiple diacritic marks with different base characters in
JKK> a sophisticated way - and a font could help here a little if it contains
JKK> some of the common combinations as precomposed glyphs.)

Yes, I agree that it could. But precomposed glyphs do not affect the
character repertoire.

-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Monday, 10 May 2004 16:34:42 UTC