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.
Comments
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.
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.
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?– 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.