Re: per-buffer language environments

[Werner LEMBERG]

> BTW, did you mean to say good *free* multilingual OpenType fonts,
> and just assume freedom, or was the omission prompted by reality?
> Freedom matters to Emacsen, of course.

Today, virtually any new multilingual font, be it `free' or not,
supports that.  For example, the TeX Gyre project provides extended
glyph sets for the URW clones of the 35 standard PS fonts, and of
course the Romanian case is handled by its OpenType tables (script
`latn', language `ROM', table `locl').

> > However, for CJK stuff, the situation is very different.
> > Virtually *no* font supports different glyphs for Chinese,
> > Japanese, and Korean.
> 
> It's not obvious to me that they should.  If you look at the
> multiple Chinese languages, Japanese, Korean, and Vietnamese, you
> see that there are clearly Chinese styles (and I suspect differences
> among Taiwanese, Cantonese, and Mandarin styles), clearly Japanese
> styles, etc. with respect to stroke endings, attitude of slanted
> strokes, contact points, and extensions at join points.  I don't
> think that people from different East Asian culture/languages would
> find compromise fonts acceptable, except perhaps in the very
> simplest of Gothic and Maru Gothic faces (Japanese names for font
> styles basically equivalent to sans-serif upright faces for Latin
> characters).  Eg, in Emacs, even as one who learned Japanese late in
> life, I've gotten used to distinguishing Chinese spam from Japanese
> spam via such stylistic differences (strictly speaking, it's
> unnecessary as the presence of kana is normally decisive).  I have
> to wonder if such stylistic fine points might not be very important
> to the comfort level of someone who is bilingual in Chinese and
> Japanese.

You've probably misunderstood me.  The idea of the script/language
tags within OpenType fonts is that you can map the input character
codes to script or language specific glyphs.  If you do so for CJK
fonts, you need about 60% more glyphs *to get locale specific correct
shapes*, as Ken Lunde has analyzed (unfortunately, his presentation is
not available in the net).  A great number of glyphs (about 40%),
however, *can* be shared among the CJK locales $(Q#|(B just think of the
characters $B0lFs;0;M8^(B which have always the same shape.

In other words, the technical problems to have a single font with
support for multiple CJK locales have been solved, but there is no
such font (neither free nor non-free, AFAIK) which incorporates this
technique.

> But as a practical matter, today if Emacs wants to display Chinese
> attractively (maybe even "correctly"), it cannot use a Japanese font
> and compromise fonts with multilingual support basically don't
> exist.  So even if support in Emacs for choosing appropriate fonts
> based on language is not needed for Romanian, it is needed for
> Han-based languages.

With `no support in Emacs needed' I mean that the burden of handling
the issue can be transferred to a library (e.g. libotf).  In case the
library says "sorry, I can't provide a locale specific font", Emacs
should do nothing for Romanian (since the user can easily install a
font with proper support), but should actually handle the case for
CJK.


    Werner