> The question is: What is the ideal solution?
The answer is: there is none.
> This seems to have a problem in that, if text is normalised,
> that can affect the layout/presentation of a document, and it
> seems to me that shouldn't happen. (Am I wrong to think that's
> a problem?)
Normalizing away compatibility characters can and often does affect
output, at least with naive output processes. The squared katakana
words at U+33xx, if converted to their compatibility equivalents,
would lose squareness, e.g.
> 2. Do not mix wide and narrow glyphs in a font, and encode text
> without any compatibility characters. Get the desired width for
> glyphs by formatting text using appropriate fonts.
This is probably a win: use English fonts for English, and Yi fonts for
Yi. But in a given system it may be more trouble than the writers
are willing to undergo. Similar problems occur with other languages;
proper Polish vowels WITH ACUTE look slightly different from their
equivalents in Western European languages.
> 3. Design applications such
> that a character such as U+0020 is encountered within a run
> that is tagged for an East Asian language [...], transduce this
> to U+3000 or do something
> similar (perhaps handled in the OS) so that the wide glyph is
This is possible, but may give trouble in specific cases, as the
implicit bidi algorithm does; you would need explicit higher-level
> 4. Encode text without any compatibility characters, permit
> mixing wide and narrow glyphs in a font and use smart font
From the writer's viewpoint, this is a variant of 2; it involves
tagging text rather than just typing it.
Schlingt dreifach einen Kreis vom dies! || John Cowan <firstname.lastname@example.org> Schliesst euer Aug vor heiliger Schau, || http://www.reutershealth.com Denn er genoss vom Honig-Tau, || http://www.ccil.org/~cowan Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer)
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT