Re: Release timelines and Unicode2 branch

[Adrian Robert <arobert@cogsci.ucsd.edu>]

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).