[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Release timelines and Unicode2 branch

From: Adrian Robert
Subject: Re: Release timelines and Unicode2 branch
Date: Thu, 22 Sep 2005 07:53:34 -0400

On Sep 22, 2005, at 2:03 AM, Steven Tamm wrote:

As for the unicode branch, the way that unicode font handling is done on the Mac (ATSUI) is different from the old-style (Quickdraw) that is used in the Carbon port. Quickdraw is based on MBTE and converting it to unicode is hard. I've done some work on rewriting the text rendering to use ATSUI, but I ran into some performance problems due to the way that fonts and styles are handled in ATSUI . It would be easier to port a GNUStep based version to use utf8 in an efficient manner based on NSLayoutManager: but any GNUStep based version of Emacs will suffer from some pretty tricky threading issues due to Apple's strange implementation of menu handling. It took a lot of effort to figure it out with Carbon. Also, maintaining backwards compatibility of font spec's is nigh impossible. But I haven't looked at the cocoa port of emacs in forever.

Yup, been there and done that in the 20.7-based Emacs on Aqua (yes, bad name.. ;). I used about 4-5 different text rendering methods at various times, and 3 or 4 of them are still in the code used in various situations. The one used on OS X 10.3/10.4 uses ATSUI to obtain fonts, but little else. Characters are passed as UTF-8 to a low-level API that NSLayoutManager itself uses. Either Quartz or Quickdraw antialiasing can be used when actually rendering.

I also tried using a pure NSLayoutManager solution. Very easy, and the huge win is that backup fonts are chosen automatically character-by-character to render glyphs that aren't in the main font. The backups are chosen to match the appearance of the main font as closely as possible. In other words, automatic "fontset" handling for free. The penalty is it was slow in the way that Emacs had to use it. Ordinarily, one throws the entire text of a buffer into the system, then tells it which parts to render. With emacs, the core sends the rendering front end just the on-screen text (as emacs "glyphs"), so you keep having to reset the layout system with whatever new text gets sent. Maybe there was a way to work around this, and we can investigate it when the time comes. (An aside, many rendering method issues also related to needing to render characters in a grid on emacs-20, which of course changes on 21+...)

As for menu handling, the way it's done in Emacs-on-Aqua is not at all optimal. A definite candidate for eventual rewrite, and maybe some of the Carbon code will prove useful there (not for the actual API calls, but the overall approach).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]