From: verdy_p (verdy_p@wanadoo.fr)
Date: Tue Aug 18 2009 - 19:56:55 CDT
"Andreas Stötzner" wrote:
> Am 13.08.2009 um 12:16 schrieb Asmus Freytag:
> > It's not a question of whether there's merit in being able to display
> > the beta using different glyphs for IPA and regular text. Let's all
> > agree that this is useful. What I meant to point out (and others have
> > confirmed) is that IPA users would view a display using the other
> > shape as
>
> > a glyph issue, not a character issue.
>
> In practice and business it doesn’t matter what you call it. The
> current situation blocks fontists and scholars to get on with each
> other. Nobody cares wether this is a glyph or a char. issue. It IS an
> issue which should get solved anyway.
Character issues and glyph issues are absolutely not in the same order of complexity to solve.
Glyph issues do not need a change in Unicode or in the way the texts are encoded or in the way they are indexed and
searched, transformed by various algorithms, edited and corrected; all corrections can be made only by involving
only once the fontists that have designed the selected font.
On the opposite, character issues involve a change in the encoding, possibly some disunification, managing the
transition between legacy and newly encoded texts, adapting the algorithms used. In addition it may need updates in
legacy texts to solve ambiguities and already existing problems that have persisted long before the effective
change.
And once this will have been done, you'll still have to finally make changes in fonts and/or possibly as well in
rendererd to support the new encoding principles (so character encoding issues are in a larger supersets of glyph
issues, that Unicode does not directly standardize).
As this does involve a lot more people (and not just Unicode or OpenType standardizers, or fontists, or system
designers, but also final users of these systems that may need to be replaced more often), the consequences are
clearly not the same, and this greatly increases the scale of induced costs for the transition or for the long_term
support of legacy texts that will never be reencoded or corrected (even if this means that they retain their
uncorrected possible ambiguities).
So if problems can be solved at the font level and/or in rendering technologies to support the correct selection of
glyph variants, because they are ONLY glyph issues, it should really be tried there first, until it gets
demonstrated that no solution can be found with a single font, and without using rich-text formats.
We already know that some "scripts" will not reach the level of being fully encodable as plain-text (at least for
now) ; this has been said for the support of old Aegyptian hieroglyphs, or for mathematic notations, because they
will require style or complex contextual layout features that are still not supported using just the current Unicode
character encoding model (notably for the layouts involving arbitrary groups of characters, which cannot be
represented by simple character properties defined with a single state variable taking value in a finite, small and
stable enumeration). However recommandations, can be made to support specific orthographies/syntaxes that renderers
can recognize and render in suitable environments.
But IPA should remain fully encoded as plain-text only, without ambiguities in any document where it is used and can
coexist with natural languages, without depending on orthographic conventions/syntaxes, or document-embeddded style,
or complex layout, and thus renderable directly using a single font in a single default style (possibly implicit or
automatically selectable by renderers, and not encoded itself, and not transported embedded within the text document
itself). This should also be the case in multiscript texts where IPA will be frequently used (if you consider IPA
notations as a script by itself, distinct and independant from the script used in the rest of the linguistic text
which may be written in Latin or Greek or other, or a reasonnable combination of them).
If support in a single font is not possible due to the current technical constraints (like the number of possible
glyphs supportable in a single OpenType font file with the current specs), the automatic selection of
alternate/fallback fonts by renderers (possibly instructed by font linking between fonts, or by designing and using
new virtual font formats for handling collections of suitable fonts) should remain possible to cover larger sets of
glyphs needed for the various scripts needed. These technical constraints are not a Unicode problem as they are not
character-level issues.
This archive was generated by hypermail 2.1.5 : Tue Aug 18 2009 - 20:00:02 CDT