Re: Latin IPA letter a

2011/6/28 Asmus Freytag <asmusf_at_ix.netcom.com>:
> On 6/28/2011 1:51 AM, Michael Everson wrote:
>>
>> On 28 Jun 2011, at 09:28, Jean-François Colson wrote:
>>
>>> In Times New Roman, which is the default font for MS Word (probably the
>>> best known word processor), the letters “a” and “ɑ” are indistinguishable in
>>> italics.
>>
>> That is a fault of the font.
>
> No, the font does what it's supposed to, which is to give the correct
> rendering of the letter 'a' for use in ordinary text. The problem is in
> Unicode's unification of the generic letter a with the IPA letter 'a', which
> has a restricted glyph range, and, as we now find out, must be treated
> differently when styles are applied.
>
> Encoding a new character is not the answer. However, encoding a standardized
> variation sequence would be the proper answer. Insisting that people have
> control over the font with which text is viewed is to a degree illusory. Not
> recognizing that fact is a weakness in Unicode's 1980's based design in this
> instance.
>
> A standardized variation sequence makes the IPA nature of the IPA 'a' more
> portable, while at the same time cleanly allowing text processing software
> to treat it like the ordinary 'a', when needed, by simply ignoring the
> variation selector.

I also fully agree. This is the solution that will be the easiest to
integrate with maximum compatibility, allowing a smooth transition
immediately. Then fonts will be updated to make use of the variation
sequence, but existing applications and encoded texts won't be broken,
whatever the fonts they were built for.

Anyway, the IPA organization should really support this encoding as
its new preferred way to represent the IPA 'a' n a way that will
explictly make the visual distinction with the IPA 'ɑ' which does not
need to be modified.

One of the main reason for adding the variation sequence is that
current font technologies (initially designed to preserve the
distinction of scripts, which does not apply here as it is still
Latin) can only be tweaked based on language (and IPA notations apply
to any language), and there's no way to specify an orthographic
distinction in OpenType for example (even if BCP 47 allows such
distinctions: OpenType does not follow the newer BCP 47
specifications).

Anyway, for applications that support BCP 47 (including text renderers
that could make use of it, independantly of the font technologies
used), it should be possible for the rendering engine to convert BCP47
language tags in order to selectively convert the untagged Latin 'a'
using the variation sequence, in order to properly select the correct
glyph in OpenType fonts.

The other solution would be to standardize in OpenType a "feature" for
phonetic notation, that the renderer could also support to include the
correct GSUB element(s) needed for proper rendering of texts tagged
with BCP47 identifiers (or similar mechanisms offerered in reich text
formats, including HTML).

But there will still remain applications where complete BCP47 tags
cannot be selectively embedded in texts, notably all the many uses of
plain-text elements such as simple database fields or "flat" CSV
files. For these, it should not shoke to include a variation sequence
in such plain-texts where the distinction is needed and there's no
simple way to isolate IPA notations embedded in other plain-text.

 (Embedding Unicode-encoded language tags using the special language
tag characters is now deprecated, let's not revive those, and anyway
it would really be overkill for just tagging a single character, when
a single standard variation selector can do the trick).

Variation sequences are now heavily used and supported for sinograms.
There's no reason not support them for Latin, where they will still
have many other uses outside IPA itself (for 'a' and 'g'), e.g. in
scientific/mathematical formulas (even if there are now separate
characters for maths needing specific glyph/stylistic designs).

Thanks.
-- Philippe.
Received on Tue Jun 28 2011 - 13:00:13 CDT