Re: font-family: IPA

> [Original Message]
> From: Chris Lilley <chris@w3.org>
>
> 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.

In addition to, yes, but LATIN SMALL LETTER A to LATIN SMALL
LETTER Z are also part of the IPA and there are glyphs that while
appropriate for general Latin text are not appropriate for use with
the IPA.  LATIN SMALL LETTER A in the IPA represents the
open "front" unrounded vowel, but the glyphs that some fonts use
for LATIN SMALL LETTER A is the one used for the open "back"
unrounded vowel that IPA encodes as LATIN SMALL LETTER ALPHA.
Outside of IPA usage, the distinction doesn't matter, but it does matter
for the IPA and this simply is something that won't be changed because
the view of the IPA (the organization not the alphabet) and the UTC
is that making that distinction clear is to be handled by the appropriate
choice of font.

>
> 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?

Only if they prescribed a subset of the glyphs used for certain Unicode
characters as being appropriate, and failing to meet those standards
would cause semantic confusion.  I'll happily agree that because of
the semantic distinction, it would be better for Unicode to disunify the
IPA characters from Latin, but they haven't and have made it quite clear
that they have no interest in doing so.

As far as Greek and Bengali are concerned.  I am not aware of any
restrictions they place on what constitutes acceptable Latin glyphs,
so no I would not propose them.

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

So {font-family:serif} and {font-family:"serif"} mean the same thing?
I was under the impression that for the keywords placing the quotes
around them gave you a way to choose the font named "serif"
even if it wasn't the default serif font.  That is what I was referring to
with the above.  If IPA were added as a keyword and someone
had used {font-family:IPA} intending to specify a font named "IPA"
then the result would be different from what had been originally
intended.  That is what makes adding keywords to 'font-family'
so problematic that I can fully appreciate the desire to keep
the property unchanged (altho I do wish that CSS3 Fonts would
deprecate {font-family:Arial} in favor of {font-family:"Arial"}.)

Still, the basic points remain.
1) There should be a simple way to specify you want the display
of Latin characters to be compatible with the IPA.
2) @font-face just isn't up for the job except on paper.
3) Giving a list of fonts for this situation is not appropriate or
  guaranteed to work.
4) Adding a keyword to 'font-family' has its own problems.

The only other solution I can think of would be to add a property:
'font-script' that would use the ISO 15924 script codes as values
and lobby to add Latp (IPA) to the list of script codes.

This would as a side benefit allow distinctions between the variants
of Syriac, between Old Church Slavonic and Cyrillic, between
normal Latin, Gaelic, and Fraktur, and between traditional and
simplified Chinese versions of the hanzi characters to be made.

Received on Monday, 10 May 2004 16:54:46 UTC