[Emacs-diffs] Changes to README.unicode

[Miles Bader]

CVSROOT:        /cvsroot/emacs
Module name:    emacs
Changes by:     Miles Bader <miles>     08/02/01 16:01:31

Index: README.unicode
===================================================================
RCS file: README.unicode
diff -N README.unicode
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ README.unicode      1 Feb 2008 16:01:23 -0000       1.2
@@ -0,0 +1,201 @@
+                                            -*-mode: text; coding: latin-1;-*-
+
+Problems, fixmes and other issues in the emacs-unicode branch
+-------------------------------------------------------------
+
+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.
+
+_Do take seriously that you don't want this branch unless you're
+actually working on it; you risk your data by actually using it._  If
+you just want to edit Unicode and/or unify iso-8859 et al, see the
+existing support and the extra stuff at
+<URL:ftp://dlpx1.dl.ac.uk/fx/emacs/Mule>, mostly now in the CVS trunk.
+(Editing support is mostly orthogonal to the internal representation.)
+
+ * 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
+----------------------------------------------------
+
+This branch 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"))