The X font naming system (XFLD) as it is documented in
ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/XLFD/xlfd.PS.gz
on pp 6-7 currently defines only the following three codes for the
SPACING field:
P = proportional
M = monospaced
C = CharCell
where P means no restrictions, M means that the width of all characters
is identical, and C means that all characters have the same width and
height and have no ink outside this glyph cell box.
C is the type of characters used with terminal emulators such as xterm
and with plain text editors such as emacs. My 6x13 Unicode font
<http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html> is an example of a C font,
because all glyph cells are exactly 6x13 pixels large (no CJK included),
and Mark Leisher's ClearlyU is a typical example of a variable width P
Unicode font.
PROBLEM:
Neither of the above codes adequately describes fonts with two cell
sizes, as they are commonly used in East Asian terminal emulators.
Roman Czyborra's GNU Unicode font <http://czyborra.com/unifont/>
currently indicates to be a C font, but this causes problems with many
applications. This font is intended to be usable with terminal emulators
and plain text editors, but it tries to cover all of Unicode including
CJK characters. It is therefore a kind of CharCell font with two related
cell sizes: 8x16 and 16x16.
There seems to be no suitable solution apart from defining a new SPACING
code for bi-width char cell fonts like unifont. My proposal would be to
add a new code B for "Biwidth CharCell fonts": B fonts underly the same
restrictions as C fonts, except that if they follow the *-iso10646-1
encoding, then those characters declared as full-width (FW) or wide (W)
characters in Unicode Technical Report #11
http://www.unicode.org/unicode/reports/tr11/
shall be exactly twice as wide as any other character. The average font
width indicated in the AVERAGE_WIDTH field shall indicate the width of a
normal (narrow) character and shall not be affected by the presence of
double-wide characters in the font.
The correct name of the GNU unifont with its mixture of 8x16 and 16x16
glyphs would therefore become something like
-gnu-unifont-medium-r-normal--16-160-75-75-b-80-iso10646-1
Does this sound reasonable?
Who is currently in charge of the above XLFD document?
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:43 EDT