1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
|
-*-mode: text; coding: latin-1;-*-
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008
Free Software Foundation, Inc.
See the end of the file for license conditions.
Problems, fixmes and other unicode-related issues
-------------------------------------------------------------
Notes by fx to record various things of variable importance. handa
needs to check them -- don't take too seriously, especially with
regard to completeness.
* SINGLE_BYTE_CHAR_P returns true for Latin-1 characters, which has
undesirable effects. E.g.:
(multibyte-string-p (let ((s "x")) (aset s 0 ?£) s)) => nil
(multibyte-string-p (concat [?£])) => nil
(text-char-description ?£) => "M-#"
These examples are all fixed by the change of 2002-10-14, but
there still exist questionalble SINGLE_BYTE_CHAR_P in the
code (keymap.c and print.c).
* Rationalize character syntax and its relationship to the Unicode
database. (Applies mainly to symbol an punctuation syntax.)
* Fontset handling and customization needs work. We want to relate
fonts to scripts, probably based on the Unicode blocks. The
presence of small-repertoire 10646-encoded fonts in XFree 4 is a
pain, not currently worked round.
With the change on 2002-07-26, multiple fonts can be
specified in a fontset for a specific range of characters.
Each range can also be specified by script. Before using
ISO10646 fonts, Emacs checks their repertories to avoid such
fonts that don't have a glyph for a specific character.
fx has worked on fontset customization, but was stymied by
basic problems with the way the default face is dealt with
(and something else, I think). This needs revisiting.
* Work is also needed on charset and coding system priorities.
* The relevant bits of latin1-disp.el need porting (and probably
re-naming/updating). See also cyril-util.el.
* Quail files need more work now the encoding is largely irrelevant.
* What to do with the old coding categories stuff?
* The preferred-coding-system property of charsets should probably be
junked unless it can be made more useful now.
* find-multibyte-characters needs looking at.
* Implement Korean cp949/UHC, BIG5-HKSCS and any other important missing
charsets.
* Lazy-load tables for unify-charset somehow?
Actually, Emacs clear out all charset maps and unify-map just
before dumping, and their are loaded again on demand the
dumped emacs. But, those maps (char tables) generated while
temacs is running can't be get rid of from the dumped emacs.
* Translation tables for {en,de}code currently aren't supported.
This should be fixed by the changes of 2002-10-14.
* Defining CCL coding systems currently doesn't work.
This should be fixed by the changes of 2003-01-30.
* iso-2022 charsets get unified on i/o.
With the change on 2003-01-06, decoding routines put `charset'
property to decoded text, and iso-2022 encoder pay attention
to it. Thus, for instance, reading and writing by
iso-2022-7bit preserve the original designation sequences.
The property name `preferred-charset' may be better?
We may have to utilize this property to decide a font.
* Revisit locale processing: look at treating the language and
charset parts separately. (Language should affect things like
speling and calendar, but that's not a Unicode issue.)
* Handle Unicode combining characters usefully, e.g. diacritics, and
handle more scripts specifically (à la Devanagari). There are
issues with canonicalization.
* Bidi is a separate issue with no support currently.
* We need tabular input methods, e.g. for maths symbols. (Not
specific to Unicode.)
* Need multibyte text in menus, e.g. for the above. (Not specific to
Unicode -- see Emacs etc/TODO, but now mostly works with gtk.)
* There's currently no support for Unicode normalization.
* Populate char-width-table correctly for Unicode chanaracters and
worry about what happens when double-width charsets covering
non-CJK characters are unified.
* Emacs 20/21 .elc files are currently not loadable. It may or may
not be possible to do this properly.
With the change on 2002-07-24, elc files generated by Emacs
20.3 and later are correctly loaded (including those
containing multibyte characters and compressed). But, elc
files generated by 20.2 and the primer are still not loadable.
Is it really worth working on it?
* Rmail won't work with non-ASCII text. Encoding issues for Babyl
files need sorting out, but rms says Babyl will go before this is
released.
* Gnus still needs some attention, and we need to get changes
accepted by Gnus maintainers...
* There are type errors lurking, e.g. in
Fcheck_coding_systems_region. Define ENABLE_CHECKING to find them.
* You can grep the code for lots of fixmes.
* Old auto-save files, and similar files, such as Gnus drafts,
containing non-ASCII characters probably won't be re-read correctly.
New font handling mechanism with font backend method
----------------------------------------------------
Emacs now contains new codes for handling fonts by multiple font
backends. The old font handling codes still exist completely parallel
to the new codes, and the new codes are used only when you configure
Emacs with the argument "--enable-font-backend".
Which font backends to use can be specified by X resource
"FontBackend". For instance, if you want to use Xft fonts only,
Emacs.FontBackend: xft
will work. If this resource is not set, Emacs tries to use all font
backends available on your graphic device.
The configure script, if invoked with "--enable-font-backend", checks
if libraries freetype and fontconfig exist. If they are both
available, macro "USE_FONT_BACKEND" is defined in src/config.h. In
that case, the existing of Xft library is checked too.
The new files are:
font.h -- header providing font-backend related structures
(most important ones are "struct font" and "struct
font_driver"), macros, and etc.
font.c -- main font handling code.
xfont.c -- font-driver on X for X core fonts.
ftfont.c -- generic font-driver for FreeType fonts providing
device-independent methods of struct font_driver.
xftfont.c -- font-driver on X using Xft for FreeType fonts
utilizing methods provided by ftfont.c.
ftxfont.c -- font-driver on X directly using FreeType fonts
utilizing methods provided by ftfont.c.
w32font.c -- font driver on w32 using Windows native fonts,
corresponding to xfont.c
So we already have codes for X. For the other systems (w32 and mac),
it seems that we need these files:
atmfont.c -- font-driver on mac using ATM fonts, corresponding
to xfont.c
As BDF fonts are currently used on w32, we may also implement these:
bdffont.c -- generic font-driver for BDF fonts, corresponding to
ftfont.c
bdfw32font.c -- font-driver on w32 using BDF fonts,
corresponding to ftxfont.c
But, as FreeType already supports BDF fonts, if FreeType and
Fontconfig are also available on w32, what we need may be:
ftw32font.c -- font-driver on w32 directly using FreeType fonts
utilizing methods provided by ftfont.c.
And, for those to work, macterm.c and macfns.c must be changed by the
similar way as xterm.c and xfns.c (the parts "#ifdef USE_FONT_BACKEND"
... "#endif" should be checked).
It may be interesting if Emacs supports a frame buffer directly and
have these font driver.
ftfbfont.c -- font-driver on FB for FreeType fonts.
bdffbfont.c -- font-driver on FB for BDF fonts.
Note: The fontset related codes are not yet matuared to work well with
the font backend method. So, for instance, even if you start Emacs
as something like this:
% emacs -fn tahoma
Non-ASCII Latin characters will not be displayed by the font "tahoma".
In such a case, please try this:
(set-fontset-font "fontset-default" 'latin '("tahoma" . "unicode-bmp"))
This file is part of GNU Emacs.
GNU Emacs is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Emacs; see the file COPYING. If not, write to the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.
|
