2011/6/28 Asmus Freytag <asm...@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.
