Re: EA width, Latin punctuation and fonts

From: John Cowan (
Date: Fri Dec 10 1999 - 12:21:25 EST wrote:

> 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
> accessed.

This is possible, but may give trouble in specific cases, as the
implicit bidi algorithm does; you would need explicit higher-level
override codes.

> 4. Encode text without any compatibility characters, permit
> mixing wide and narrow glyphs in a font and use smart font
> technology.

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 <> Schliesst euer Aug vor heiliger Schau, || Denn er genoss vom Honig-Tau, || 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