emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choice of fonts displaying etc/HELLO


From: Stephen J. Turnbull
Subject: Re: Choice of fonts displaying etc/HELLO
Date: Thu, 07 Aug 2008 00:52:13 +0900

Kenichi Handa writes:
 > In article <address@hidden>, "Stephen J. Turnbull" <address@hidden> writes:

 > > Emacs could adapt fontconfig's "orthography" mechanism instead.
 > 
 > But, for selecting fonts for symbols (the current case is
 > U+2200 [FOR ALL]), such a mechanism doesn't work.

Of course.  Here's how I think about it.

Historically, East Asian coded character sets have tended to try to be
UCSes, including everything that might be needed, since it was
possible in a MBCS.  Trying to implement single octet codes with code
page switching made no sense.  That approach is unintuitive to
Westerners who are used to having separate "code pages" or fonts for
specialty usage like mathematics, and it has its practical limits for
East Asians, too, what with the addition of 11,000 pre-composed Hangul
and the CNS with ~80,000 code points.  Of course, now we have a true
UCS (even though it has some problems) in Unicode, so we should use
it.  And now FOR ALL should not be considered a "Japanese" character
even if it does have a code point in some JIS standard.  I would say
the same for GREEK SMALL LETTER ALPHA.

It's also very annoying in practical use (in Emacs, anyway) that GREEK
SMALL LETTER ALPHA (not to mention LATIN SMALL LETTER A) has multiple
encodings in the "native" coded character set and several others.

Of course this can be useful if you happen not to have a math font but
do have a Greek font or Japanese font that contains alpha or for all.
For those purposes, fontconfig's character set feature is exactly what
you want.

 > In addition, currently, Emacs doesn't know in which langauge
 > a text is written.  So, we can't use an appropriate ":lang"
 > property of fontconfig.

Well, for most users almost all of the time we do.  The LANG
environment variable will tell us.  This will make most users very
happy at little cost in coding.

Agreed, in multilingual use, we can't use fontconfig directly.  My
idea is that fontconfig has already constructed a database of language
repertoires and operations which might help in doing analysis of a
text to determine its language.  Also, instead of using the UCS-like
repertoires of East Asian scripts to determine character categories, I
suggest the fontconfig repertoires are more appropriate and will lead
to more attractive presentation for users who have appropriate fonts.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]