[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).
- Re: Release timelines and Unicode2 branch, (continued)
- Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/13
- Re: Release timelines and Unicode2 branch, Stefan Monnier, 2005/09/13
- Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/14
- Re: Release timelines and Unicode2 branch, Adrian Robert, 2005/09/14
- Re: Release timelines and Unicode2 branch, Stefan Monnier, 2005/09/14
- Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/15
- Re: Release timelines and Unicode2 branch, Adrian Robert, 2005/09/19
- Re: Release timelines and Unicode2 branch, David Kastrup, 2005/09/20
- Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/21
- Re: Release timelines and Unicode2 branch, Steven Tamm, 2005/09/22
- Re: Release timelines and Unicode2 branch,
Adrian Robert <=
- Re: Release timelines and Unicode2 branch, Stefan Monnier, 2005/09/22
- Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/23
Re: Release timelines and Unicode2 branch, Richard M. Stallman, 2005/09/13