IPA support, Greek letters in IPA, IPA small caps, and display typefaces

Adam Jagosz

I noticed that few display typefaces support the IPA. Why bother? Well, there are linguists and teachers active on Instagram, so the display fonts used there to decorate the stories would be much sweeter with IPA!

The few display fonts I could find that contained the characters in the IPA range, failed to also include the Greek letters that are part of the IPA: beta (β), theta (θ), chi (χ).

Sidenote: I read somewhere that an IPA-specific chi should be used in case the font's default Greek chi shares its design with /x. It took me quite a few minutes to flick the thick covers of dust from this obscure character: it's Latin small letter chi U+AB53. I wonder how many input tools use it instead of the Greek chi. This one doesn't. For fonts that support also Greek and feature a non-descending chi, maybe a contextual substitution could be implemented?*

It is maybe also worth noting that Latin small letter gamma doesn't necessarily share the design with Greek gamma: I suspect the loop should be always present in the Latin one. I wonder about the latin phi: it usually features horizontal UC-style serifs, which I find visually disturbing. Is this necessary? Isn't using the asc-desc form instead of the cursive desc-only form enough differentiation?

Of lesser bugs, small caps fonts in the families I investigated sometimes contained small caps versions of component characters (ʍ, ʌ) but not manually drawn ones (ɪ). Small caps don't make any sense for IPA, except for the IPA letters used for some African orthographies (the ones with the hook: ɓɗɠɦŋʋ, then Latin gamma: ɣ and some more: ɛɔ). What is the solution?

Perhaps stop creating SC cuts and provide OpenType small caps instead. But if you insisted... Maybe stretch the non-capitalizable IPA letters up to the SC height, if different than x-height? But if we consider the OT solution, again, what if someone applies SC to an IPA string containing a letter used for African that does have a SC variant? Maybe inhibit the substitution if a non-African IPA letter is found in the same word (that would be a lot of long lines in a .fea file and the word length would be limited, but a simplistic solution could just check the letter before and after). Or conversely, if SC IPA is designed, provide two versions of SC African IPA letters, one based on the UC, and one on the LC.

All this agonizing is of course largely theoretical and futile. But then again, indirectly quoting from somewhere on this forum, what the font designer deems shouldn't be done, the graphic designer will do, or something along these lines.

Bottomline: don't forget to provide your font with beta, theta, and chi from the Greek and Coptic range if you plan to support IPA. Possibly include the Latin chi U+AB53 from the abyss-of-Unicode Latin Extended-E range.

* Sometimes I feel like I'm against meddling with character substitution like Romanian comma accents. It is not the font's responsibility to correct the user's typing errors or the layout software manufacturer's error... But.

André G. Isaak

The few display fonts I could find that contained the characters in the IPA range, failed to also include the Greek letters that are part of the IPA: beta (β), theta (θ), chi (χ).

Technically, none of the IPA characters should be viewed as Greek characters, even though they have Greek origins. The IPA is modelled on the Latin alphabet, and all characters should follow latin rather than Greek design principles. Unicode has been gradually disunifying the two, but theta still remains. Depending on the font, a greek theta might be usable provided it is upright and doesn’t have a cursive character.

For other characters, such as latin small letter beta, phi, chi, etc. many IPA fonts in common use were designed prior to these letters being assigned their own codepoints, and I suspect many linguists aren’t aware the these letters have been assigned their own codepoints.

I wonder about the latin phi: it usually features horizontal UC-style serifs, which I find visually disturbing. Is this necessary?

If someone is modelling latin phi after uppercase greek phi, that would be a mistake. The serifs on this should be the same serifs one finds on lowercase letters. A greek style phi simply doesn’t harmonize well with other latin letters.

The real problem, I think, lies in the fact that, while 'IPPH' and 'APPH' language tags have been defined, few if any layout applications actually allow one to select these. Because of this, any font which attempts to be usable both as a latin (or latin and greek) text face and a phonetic face (which is certainly a reasonable goal) is going to run into problems due to the unicameral nature of phonetic transcription and the fact that many stylistic variants which would be perfectly acceptable for latin and/or greek would not be acceptable in phonetic transcription.

James Puckett

Remember that study that claimed people recall facts they read better when a display font it used? Well these fonts can target the booming linguistics textbook market! 

John Hudson

I read somewhere that an IPA-specific chi should be used in case the font's default Greek chi shares its design with /x. It took me quite a few minutes to flick the thick covers of dust from this obscure character: it's Latin small letter chi U+AB53. I wonder how many input tools use it instead of the Greek chi.

The Latin character encodings for IPA letters derived from Greek are relatively new additions to Unicode, so it isn't a surprise that they're not widely supported. Their use should be encouraged, but in the meantime I recommend including them in fonts but also mapping these glyphs as IPPH variants of the Greek characters. If you're making fonts for clients who are using software that doesn't easily support IPPH variants, you could also include them in a stylistic set feature.

John Savard

Surely you should instead make a separate font specifically for IPA because that's the only way to ensure it will work properly with all software.

André G. Isaak

Surely you should instead make a separate font specifically for IPA because that's the only way to ensure it will work properly with all software.

One can certainly adopt that approach, but I view that as a short-term solution. Ideally, it should be possible to design a single font which is appropriate for both body text and phonetic examples. Applications are more likely to start offering the necessary support if people are actually designing fonts which make use of IPPH language tags and so forth.

John Savard

André G. Isaak said:

One can certainly adopt that approach, but I view that as a short-term solution.

I do agree that it's an imperfect solution; the standard provides for the "right" way to do these things.

But as for short-term - it will be on January 14, 2020 that Windows 7 will stop receiving security updates, and become unsafe to use on the Internet. WordPad for Windows 7 does not support these features - and, for that matter, at the present time, I'm pretty sure that WordPad for Windows 10, or whatever its equivalent is called there, doesn't either.

Fonts ought to work everywhere, on even the most basic tools that let you create documents which use different typefaces. Not just desktop publishing programs, or high-end word processors.

Still, I see that there is a system for using advanced OpenType features in Libre Office 5.3 and above. Unfortunately, it involves creating an alternate entry for the font, where its name is (fontname):(feature) rather than something you can select by pointing and clicking within the application.

Using those features is the best way to go, because that is the most effective way to provide alternates. I think the best thing to do is to provide a font package that includes both the OpenType font were alternates are properly expressed using such features, and separate fonts so that the alternate characters are accessible in any application. I think it will be a long time before one can use OpenType alternates even in programs like WordPad, if ever.

Adam Jagosz

FWIW, Windows 10's basic Notepad app has OT support. (Wordpad doesn't).
To restate what the issue is: we are talking about having an IPA-specific font cut that features:

• a normal, descending and ascending /beta, designed to harmonize with Latin (stress-wise and whatnot)
• a descending /chi, designed to harmonize with Latin
• a non-cursive /theta, designed to harmonize with Latin
• possibly a non-cursive /phi, designed to harmonize with Latin (just in case, since the codepoint for IPA phi has been around for a while)
• a two-storey /a
• the /g doesn't really matter since both variants are acceptable, and a codepoint is well established, though not always used

Anything else?

Andreas Stötzner

…the best thing to do is to provide a font package that includes both the OpenType font … and separate fonts so that the alternate characters are accessible in any application …

– sounds strange to me. The more complications you build into your product, the more peculiarities you promise to adress – the more querries and complaints you will get from users. We have a defined set of phonetic characters based on a standard encoding and this should be the spine of every usage scenario. I was never a believer in using OT alternates to conceal unsolved glyph design matters.