Re: Status of IPA patch?

[Juri Linkov <juri@jurta.org>]

>  > >  > The omission of those two was intentional, since U+20A7 is
>  > >  > equivalent to tʃ (note that that digraph doesn’t include the tie
>  > >  > that would be necessary to have it as a phoneme distinct from /t/
>  > >  > followed by /ʃ/) and g is equivalent to U+0261 for the purposes of
>  > >  > the IPA.
>  >
>  > I don’t understand why do you omit U+20A7 and U+0261 if they exist in
>  > X-SAMPA and Kirshenbaum?
>
> The IPA standards (which X-SAMPA and Kirshenbaum build on) define _U+20A7_
> and _U+0261_ as being equivalent to _a succession of U+0074 and U+0283_, and
> _U+0067_, respectively. The former two code points just represent
> compatibility glyphs (with U+20A7 leading to needless confusion, since
> people might reasonably believe that it meant the same as U+0074 U+2040
> U+0283, including the tie I mention above).

Since these are three most popular ways to represent this sound,
I think we should support all of them:

1. a ligature ʧ (U+02A7)
2. two symbols tʃ (U+0074 U+0283)
3. two symbols joined with a tie t͡ʃ (U+0074 U+2040 U+0283)

This can be done with a non-deterministic quail guidance string
displaying a menu of possible variants.

> Kirshenbaum mentions ASCII g as mapping to both U+0067 and U+0261 without
> comment. Including both would not add to the semantic range of what the user
> can input (in terms of the IPA), and would again be needlessly confusing
> (the user types g; wonders if 0 or 1 is more appropriate; when it doesn’t
> actually matter,

I agree there is no sense to create a menu of both U+0067 and U+0261,
so we should keep only the IPA symbol U+0261, because U+0067 is easy
to type anyway without an input method.

> and U+0067 is always more certain to be preserved by software).

The problem of preserving by software is not specific to U+0261,
but rather to the most of IPA symbols.

-- 
Juri Linkov
http://www.jurta.org/emacs/