]> code.delx.au - gnu-emacs/blobdiff - README.unicode
(unidata.txt): Don't use $<, it's non-portable in this context.
[gnu-emacs] / README.unicode
index bcaff98627f4c651f78c9f791c208cc5615ae508..4e5b0993559b5f1138633d0c7f14a6cb8357127c 100644 (file)
@@ -1,19 +1,16 @@
                                             -*-mode: text; coding: latin-1;-*-
 
-Problems, fixmes and other issues in the emacs-unicode branch
+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.
 
-_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
@@ -21,7 +18,7 @@ existing support and the extra stuff at
    (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
+       there still exist questionable SINGLE_BYTE_CHAR_P in the
        code (keymap.c and print.c).
 
  * Rationalize character syntax and its relationship to the Unicode
@@ -61,10 +58,10 @@ existing support and the extra stuff at
 
  * 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
+       Actually, Emacs clears out all charset maps and unify-map just
+       before dumping, and they are loaded again on demand by the
        dumped emacs.  But, those maps (char tables) generated while
-       temacs is running can't be get rid of from the dumped emacs.
+       temacs is running can't be removed from the dumped emacs.
 
  * Translation tables for {en,de}code currently aren't supported.
 
@@ -86,7 +83,7 @@ existing support and the extra stuff at
 
  * 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.)
+   spelling 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
@@ -102,7 +99,7 @@ existing support and the extra stuff at
 
  * There's currently no support for Unicode normalization.
 
- * Populate char-width-table correctly for Unicode chanaracters and
+ * Populate char-width-table correctly for Unicode characters and
    worry about what happens when double-width charsets covering
    non-CJK characters are unified.
 
@@ -135,35 +132,85 @@ existing support and the extra stuff at
 New font handling mechanism with font backend method
 ----------------------------------------------------
 
-This branch now contains new codes for handling fonts by multiple font
+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" and run Emacs with the
-same argument.
+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
-existing of libraries freetype and fontconfig.  If they are both
-available, macro "USE_FONT_BACKEND" is defined in src/config.h.
-In that case, the exiting of Xft library is checked too.
+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.
-       xftfont.c -- font-driver on X using Xft for FreeType fonts.
-       ftxfont.c -- font-driver on X not using Xft for FreeType fonts.
-
-So we already have codes for X.  For the other systems (win32 and mac),
+       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:
-       bdffont.c -- generic font-driver for BDF fonts.
-       w32font.c -- font driver on win32 using Windows native fonts.
-       w32bdffont.c -- font-driver on win32 using BDF fonts.
-       atmfont.c -- font-driver on mac using ATM fonts.
-
-It may be interesting if Emacs supports frame buffer directly and have
-these font driver.
+       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.
 
-Several other files have "#ifdef USE_FONT_BACKEND ... #endif" at the
-place where changed for this new font codes.
+Note: The fontset related codes are not yet matured 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"))
+
+\f
+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.