Re: font-family: IPA

On Monday, May 10, 2004, 4:12:42 PM, Ernest wrote:



>> [Original Message]
>> From: Chris Lilley <chris@w3.org>
>>
>> On Sunday, May 9, 2004, 10:50:05 PM, Ian wrote:
>>
>>
>> IH> On Sun, 9 May 2004, Ernest Cline wrote:
>> >>
>> >> [no way to detect IPA fonts]
>>
>> IH> Not really much point adding it to CSS then.
>>
>> I agree that a special-case addition to CSS is not needed.
>>
>> Puzzled by the references to Panose (a system of describing
>> Latin glyph design axes) to this - the correct descriptor is clearly
>> unicode-range.

EC> But you see, as far as the UTC is concerned, IPA is just Latin
EC> characters

But not basic Latin characters. Its a Latin extension block as well.

EC> with the correct font, so in theory Panose would
EC> be appropriate, if they had the necessary combination of
EC> descriptor digits, but it doesn't.

Panose would be appropriate to describe the design and to choose
between two different designs of IPA font, say, one of which was more
oblique or had slab serifs or whatever.



>> http://www.w3.org/TR/CSS2/fonts.html#dataqual
>>
>> IPA extensions is the 0250 block (0250 to 02AF)
>>
>> http://www.unicode.org/charts/PDF/U0250.pdf
>>
>> 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)
>>  }

EC> Are there any UA's that actually try to do intelligent font matching?

You would note that this example was a downloadable font not an
intelligent font match. I agree intelligent match is less common, and
font synthesis is unimplemented as far as I know.

EC> And if there are, do they search all local fonts for a possible match?

EC> I thought that @font-face required you to list all potential matches.

CSS1 had a mythical database of fonts and their properties.
CSS2 allows you to add to this database; it doesn't require you to
completely replace it.

I understand that yeslogic CSS renderer actually ships with a database
in CSS2 @font-face format that can be customized to suit.

EC> Unless it can search among all local fonts (checking first the ones
EC> given in the 'src' descriptor of course) then it does not achieve
EC> what I was hoping for from .phonetic {font-family:IPA}

EC> Given the mess that @font-face is in at the moment, this approach
EC> while messy might solve the problem.  The lack of interoperable
EC> @font-face implementations is probably why I didn't think of this
EC> in the first place, especially since I didn't  want to have to care about
EC> providing a list of font names.  For the purposes envisaged, this is
EC> nowhere near as elegant as adding one keyword to 'font-family'
EC> would be.

I don't see it as elegant and I do see it as a mess. Would you propose
font-family: Greek and font-family:Bengali and so on, as well?

EC> If at this point intelligent font matching is just a six year old paper
EC> specification, it still might make sense to add another keyword.
EC> I am aware of the slight degree of backward compatibility it would
EC> cause, but I seriously doubt that a font named "IPA" would be
EC> anything other than an IPA font, so I wouldn't consider it a serious
EC> problem if anyone had left the quotes off the font name and
EC> expecting to get the font named IPA instead of just a font that
EC> correctly handles IPA.

The quotes are not required in any case unless the font family name
includes spaces, so the two are exactly equivalent.





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

Received on Monday, 10 May 2004 15:46:08 UTC