jasonrumney.net

Kenichi Handa has been hard at work on a Unicode based Emacs for some years now. For Windows users, there is nothing radical in the default build, a few more languages are supported, and a wider range of Unicode characters, but the Windows specific code has only been updated enough to keep working. In future, optimisations and simplifications can be made due to the internal encodings of Emacs and Windows being both based on Unicode. Messing around with code pages to get fonts displaying will be a thing of the past, and can be already thanks to the new font backend.

While work progressed in parallel on Emacs 22 and the Unicode codebase, there were several other developments happening outside the core Emacs development team. Multiple terminal support (multi-tty) has already been merged with the CVS trunk, though it doesn't mean much to Windows users. Limitations in the way Windows handles console output mean that it is never likely to provide much in the way of new features on Windows, though it may be possible to rid ourselves of the runemacs.exe hack without sacrificing console support using the multi-tty feature.

Another new development was support for X freetype font rendering. On the face of it, this doesn't seem to mean much to Windows users either, but after being merged with the Unicode branch, it has been refactored into a new font backend design, with better support for unicode fonts. No longer are fonts defined by their character-set, Emacs can make use of font meta-data to determine which Unicode subranges each font supports. Currently the font backend is not enabled by default, but has to be enabled with a configure option. A backend has been implemented for Windows native fonts, and is ready for testing.

• Checking out the Unicode branch:
  cvs -d:pserver:anonymous@cvs.sv.gnu.org:/sources/emacs co -r emacs-unicode-2 emacs
• Building Emacs with font backend support:
  cd emacs\nt
configure --enable-font-backend
make bootstrap

Future work

The new font backend is noticeably slower on Windows. A lot of this is probably down to the fact that the old font code cached the font metrics for ASCII characters of fixed width fonts, whereas the new font backend does no such caching yet. We can probably do a better job of caching by calculating which ranges of characters the fixed width applies to, rather than just ASCII. We might even allow multiple such range/width combinations to be associated with a font, to speed up CJK text display (where characters in the font are one of two widths).

There is no support for BDF fonts in the new font backend. BDF fonts will be given their own font backend, hopefully mostly reusable on other platforms.

A Uniscribe font backend may be introduced to enable some of the more advanced layout features in Windows XP and later. The new font backend design makes it easier to add new support like this without complex dynamic loading logic to support older versions of Windows.

This is a work in progress that I started some time ago, but haven't had much time for lately. Richard Stallman doesn't like the set-font-for-face-at-point interface, and wants it to work more like a word-processor where you change the font of some text, without other text in that face changing, and without needing to know about faces.

• x-font.el

If you've been watching the CVS commits lately, you'll have noticed that there has been a flurry of activity recently concerning image support for Windows.

So how do you get this going?

Image support will be compiled in if the necessary headers are in your include path. You can extend the include path for msvc by setting the INCLUDE environment variable. For gcc, the INCLUDEPATH environment variable has the same purpose. An alternative for both compilers is to specify --with-cflags "-I ..." when running the configure.bat script.

If you don't want support for an image format for some reason (eg bugginess), you can force configure.bat to skip detecting that library. There are --without-... options for all image formats that use external libraries.

The PNG library also depends on zlib, at both compile and run time. TIFF depends on JPEG at run time, but it is possible to compile an Emacs with TIFF support without the JPEG headers. There appear to be some incompatibilities between some binary versions of libraries. The safest option is to compile the libraries yourself, then use the headers from those versions (which may include configuration info) to build Emacs.

Emacs uses DLL versions of the image libraries. You can compile these yourself, or download them from the GnuWin32 project (the DLLs are in the ...-bin.zip packages) or elsewhere.

An alternative to libXpm is elisp XPM support written by Oliver Scholz, with some modifications by me to support the splash-screen. Oliver's original version can be found in the emacs-devel archives on mail.gnu.org, my modified versions are below (mostly in image-add.el, but there may be some differences in xpm.el):

• state-m.el: A state machine in elisp.
• xpm.el: XPM decoder.
• image-add.el: Replacements for some functions in image.el

Usage: (require 'image-add)