ATSUI support on Carbon Emacs

ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

At the request of the maintainer, I installed ATSUI support on Carbon
Emacs to the trunk.  It does not change anything unless -DUSE_ATSUI is
specified at compile time.  It is still somewhat experimental, and has
some known problems:

  * Cursor movement is sometimes slow because of the excessive redraw
    of overlapping/overlapped rows.
    http://lists.gnu.org/archive/html/emacs-devel/2005-09/msg00705.html

  * Tall characters get thicker because they are overdrawn when
    overlapping rows are redrawn.  This is the verical version of the
    following problem:
    http://lists.gnu.org/archive/html/emacs-devel/2005-01/msg00729.html

  * Sole diacritical marks and right-to-left texts are not displayed
    correctly.

  * A JISX0212 character in HELLO (C-h h) is not displayed by default.
    (I don't mean all of the remaining characters are displayed by
    default.)  A workaround is to evaluate
    (define-translation-hash-table 'ucs-mule-cjk-to-unicode
     ucs-mule-cjk-to-unicode).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 01 Oct 2005 20:28:45 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>   * Tall characters get thicker because they are overdrawn when
>     overlapping rows are redrawn.  This is the verical version of
>     the following problem:
>     http://lists.gnu.org/archive/html/emacs-devel/2005-01/msg00729.html

Some changes to the platform-independent part are needed to fix this,
just like the horizontal one.  In the following patch, overlapping
glyph drawing is divided into several cases: overlapping with the
preceding rows, overlapping with the succeeding rows, both of them,
and overlapping in the erased cursor area.  And clipping rectangles
are calculated according to the type of overlapping.

May I install this?  Such changes will be needed when we support other
anti-aliasing environments such as Xft.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/dispextern.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/dispextern.h,v
retrieving revision 1.209
diff -c -r1.209 dispextern.h
*** src/dispextern.h	30 Sep 2005 22:38:16 -0000	1.209
--- src/dispextern.h	6 Oct 2005 07:03:05 -0000
***************
*** 1182,1191 ****
       stipple pattern.  */
    unsigned stippled_p : 1;
  
!   /* 1 means only the foreground of this glyph string must be drawn,
!      and we should use the physical height of the line this glyph
!      string appears in as clip rect.  */
!   unsigned for_overlaps_p : 1;
  
    /* The GC to use for drawing this glyph string.  */
  #if defined(HAVE_X_WINDOWS) || defined(MAC_OS)
--- 1182,1199 ----
       stipple pattern.  */
    unsigned stippled_p : 1;
  
! #define OVERLAPS_PRED		(1 << 0)
! #define OVERLAPS_SUCC		(1 << 1)
! #define OVERLAPS_BOTH		(OVERLAPS_PRED | OVERLAPS_SUCC)
! #define OVERLAPS_ERASED_CURSOR 	(1 << 2)
!   /* Non-zero means only the foreground of this glyph string must be
!      drawn, and we should use the physical height of the line this
!      glyph string appears in as clip rect.  If the value is
!      OVERLAPS_ERASED_CURSOR, the clip rect is restricted to the rect
!      of the erased cursor.  OVERLAPS_PRED and OVERLAPS_SUCC mean we
!      draw overlaps with the preceding and the succeeding rows,
!      respectively.  */
!   unsigned for_overlaps_p : 3;
  
    /* The GC to use for drawing this glyph string.  */
  #if defined(HAVE_X_WINDOWS) || defined(MAC_OS)
***************
*** 2266,2272 ****
       This function is called from redraw_overlapping_rows after
       desired rows have been made current.  */
    void (*fix_overlapping_area) P_ ((struct window *w, struct glyph_row *row,
! 				    enum glyph_row_area area));
  
  #ifdef HAVE_WINDOW_SYSTEM
  
--- 2274,2280 ----
       This function is called from redraw_overlapping_rows after
       desired rows have been made current.  */
    void (*fix_overlapping_area) P_ ((struct window *w, struct glyph_row *row,
! 				    enum glyph_row_area area, int));
  
  #ifdef HAVE_WINDOW_SYSTEM
  
***************
*** 2664,2670 ****
  extern struct cursor_pos output_cursor;
  
  extern void x_fix_overlapping_area P_ ((struct window *, struct glyph_row *,
! 					enum glyph_row_area));
  extern void draw_phys_cursor_glyph P_ ((struct window *,
  					  struct glyph_row *,
  					  enum draw_glyphs_face));
--- 2672,2678 ----
  extern struct cursor_pos output_cursor;
  
  extern void x_fix_overlapping_area P_ ((struct window *, struct glyph_row *,
! 					enum glyph_row_area, int));
  extern void draw_phys_cursor_glyph P_ ((struct window *,
  					  struct glyph_row *,
  					  enum draw_glyphs_face));
***************
*** 2682,2687 ****
--- 2690,2697 ----
  extern void x_draw_vertical_border P_ ((struct window *w));
  
  extern void frame_to_window_pixel_xy P_ ((struct window *, int *, int *));
+ extern int get_glyph_string_clip_rects P_ ((struct glyph_string *,
+ 					    NativeRectangle *, int));
  extern void get_glyph_string_clip_rect P_ ((struct glyph_string *,
  					    NativeRectangle *nr));
  extern Lisp_Object find_hot_spot P_ ((Lisp_Object, int, int));
Index: src/dispnew.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/dispnew.c,v
retrieving revision 1.356
diff -c -r1.356 dispnew.c
*** src/dispnew.c	1 Sep 2005 14:16:19 -0000	1.356
--- src/dispnew.c	6 Oct 2005 07:03:06 -0000
***************
*** 4035,4057 ****
  
        if (row->overlapping_p && i > 0 && bottom_y < yb)
  	{
! 	  if (row->used[LEFT_MARGIN_AREA])
! 	    rif->fix_overlapping_area (w, row, LEFT_MARGIN_AREA);
  
! 	  if (row->used[TEXT_AREA])
! 	    rif->fix_overlapping_area (w, row, TEXT_AREA);
  
! 	  if (row->used[RIGHT_MARGIN_AREA])
! 	    rif->fix_overlapping_area (w, row, RIGHT_MARGIN_AREA);
  
! 	  /* Record in neighbour rows that ROW overwrites part of their
! 	     display.  */
! 	  if (row->phys_ascent > row->ascent && i > 0)
! 	    MATRIX_ROW (w->current_matrix, i - 1)->overlapped_p = 1;
! 	  if ((row->phys_height - row->phys_ascent
! 	       > row->height - row->ascent)
! 	      && bottom_y < yb)
! 	    MATRIX_ROW (w->current_matrix, i + 1)->overlapped_p = 1;
  	}
  
        if (bottom_y >= yb)
--- 4035,4067 ----
  
        if (row->overlapping_p && i > 0 && bottom_y < yb)
  	{
! 	  int overlaps = 0;
  
! 	  if (MATRIX_ROW_OVERLAPS_PRED_P (row)
! 	      && !MATRIX_ROW (w->current_matrix, i - 1)->overlapped_p)
! 	    overlaps |= OVERLAPS_PRED;
! 	  if (MATRIX_ROW_OVERLAPS_SUCC_P (row)
! 	      && !MATRIX_ROW (w->current_matrix, i + 1)->overlapped_p)
! 	    overlaps |= OVERLAPS_SUCC;
  
! 	  if (overlaps)
! 	    {
! 	      if (row->used[LEFT_MARGIN_AREA])
! 		rif->fix_overlapping_area (w, row, LEFT_MARGIN_AREA, overlaps);
  
! 	      if (row->used[TEXT_AREA])
! 		rif->fix_overlapping_area (w, row, TEXT_AREA, overlaps);
! 
! 	      if (row->used[RIGHT_MARGIN_AREA])
! 		rif->fix_overlapping_area (w, row, RIGHT_MARGIN_AREA, overlaps);
! 
! 	      /* Record in neighbour rows that ROW overwrites part of
! 		 their display.  */
! 	      if (overlaps & OVERLAPS_PRED)
! 		MATRIX_ROW (w->current_matrix, i - 1)->overlapped_p = 1;
! 	      if (overlaps & OVERLAPS_SUCC)
! 		MATRIX_ROW (w->current_matrix, i + 1)->overlapped_p = 1;
! 	    }
  	}
  
        if (bottom_y >= yb)
Index: src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1057
diff -c -r1.1057 xdisp.c
*** src/xdisp.c	1 Oct 2005 20:42:09 -0000	1.1057
--- src/xdisp.c	6 Oct 2005 07:03:06 -0000
***************
*** 1768,1782 ****
  }
  
  /* EXPORT:
!    Return in *R the clipping rectangle for glyph string S.  */
  
! void
! get_glyph_string_clip_rect (s, nr)
       struct glyph_string *s;
!      NativeRectangle *nr;
  {
    XRectangle r;
  
    if (s->row->full_width_p)
      {
        /* Draw full-width.  X coordinates are relative to S->w->left_col.  */
--- 1768,1787 ----
  }
  
  /* EXPORT:
!    Return in RECTS[] at most N clipping rectangles for glyph string S.
!    Return the number of stored rectangles.  */
  
! int
! get_glyph_string_clip_rects (s, rects, n)
       struct glyph_string *s;
!      NativeRectangle *rects;
!      int n;
  {
    XRectangle r;
  
+   if (n <= 0)
+     return 0;
+ 
    if (s->row->full_width_p)
      {
        /* Draw full-width.  X coordinates are relative to S->w->left_col.  */
***************
*** 1823,1828 ****
--- 1828,1850 ----
      {
        r.y = WINDOW_HEADER_LINE_HEIGHT (s->w);
        r.height = window_text_bottom_y (s->w) - r.y;
+ 
+       /* Alas, the above simple strategy does not work for the
+ 	 environments with anti-aliased text: if the same text is
+ 	 drawn onto the same place multiple times, it gets thicker.
+ 	 If the overlap we are processing is for the erased cursor, we
+ 	 take the intersection with the rectagle of the cursor.  */
+       if (s->for_overlaps_p & OVERLAPS_ERASED_CURSOR)
+ 	{
+ 	  XRectangle rc, r_save = r;
+ 
+ 	  rc.x = WINDOW_TEXT_TO_FRAME_PIXEL_X (s->w, s->w->phys_cursor.x);
+ 	  rc.y = s->w->phys_cursor.y;
+ 	  rc.width = s->w->phys_cursor_width;
+ 	  rc.height = s->w->phys_cursor_height;
+ 
+ 	  x_intersect_rectangles (&r_save, &rc, &r);
+ 	}
      }
    else
      {
***************
*** 1881,1891 ****
  	}
      }
  
  #ifdef CONVERT_FROM_XRECT
!   CONVERT_FROM_XRECT (r, *nr);
  #else
!   *nr = r;
  #endif
  }
  
  
--- 1903,1973 ----
  	}
      }
  
+   if ((s->for_overlaps_p & OVERLAPS_BOTH) == 0
+       || (s->for_overlaps_p & OVERLAPS_BOTH) == OVERLAPS_BOTH && n == 1)
+     {
  #ifdef CONVERT_FROM_XRECT
!       CONVERT_FROM_XRECT (r, *rects);
  #else
!       *rects = r;
! #endif
!       return 1;
!     }
!   else
!     {
!       /* If we are processing overlapping and allowed to return
! 	 multiple clipping rectangles, we exclude the row of the glyph
! 	 string from the clipping rectangle.  This is to avoid drawing
! 	 the same text on the environment with anti-aliasing.  */
! #ifdef CONVERT_FROM_XRECT
!       XRectangle rs[2];
! #else
!       XRectangle *rs = rects;
! #endif
!       int i = 0, row_y = WINDOW_TO_FRAME_PIXEL_Y (s->w, s->row->y);
! 
!       if (s->for_overlaps_p & OVERLAPS_PRED)
! 	{
! 	  rs[i] = r;
! 	  if (r.y + r.height > row_y)
! 	    if (r.y < row_y)
! 	      rs[i].height = row_y - r.y;
! 	    else
! 	      rs[i].height = 0;
! 	  i++;
! 	}
!       if (s->for_overlaps_p & OVERLAPS_SUCC)
! 	{
! 	  rs[i] = r;
! 	  if (r.y < row_y + s->row->visible_height)
! 	    if (r.y + r.height > row_y + s->row->visible_height)
! 	      {
! 		rs[i].y = row_y + s->row->visible_height;
! 		rs[i].height = r.y + r.height - rs[i].y;
! 	      }
! 	    else
! 	      rs[i].height = 0;
! 	  i++;
! 	}
! 
!       n = i;
! #ifdef CONVERT_FROM_XRECT
!       for (i = 0; i < n; i++)
! 	CONVERT_FROM_XRECT (rs[i], rects[i]);
  #endif
+       return n;
+     }
+ }
+ 
+ /* EXPORT:
+    Return in *NR the clipping rectangle for glyph string S.  */
+ 
+ void
+ get_glyph_string_clip_rect (s, nr)
+      struct glyph_string *s;
+      NativeRectangle *nr;
+ {
+   get_glyph_string_clip_rects (s, nr, 1);
  }
  
  
***************
*** 20588,20600 ****
  #ifdef HAVE_WINDOW_SYSTEM
  
  /* EXPORT for RIF:
!    Fix the display of area AREA of overlapping row ROW in window W.  */
  
  void
! x_fix_overlapping_area (w, row, area)
       struct window *w;
       struct glyph_row *row;
       enum glyph_row_area area;
  {
    int i, x;
  
--- 20670,20684 ----
  #ifdef HAVE_WINDOW_SYSTEM
  
  /* EXPORT for RIF:
!    Fix the display of area AREA of overlapping row ROW in window W
!    with respect to the overlapping part OVERLAPS.  */
  
  void
! x_fix_overlapping_area (w, row, area, overlaps)
       struct window *w;
       struct glyph_row *row;
       enum glyph_row_area area;
+      int overlaps;
  {
    int i, x;
  
***************
*** 20617,20623 ****
  
  	  draw_glyphs (w, start_x, row, area,
  		       start, i,
! 		       DRAW_NORMAL_TEXT, 1);
  	}
        else
  	{
--- 20701,20707 ----
  
  	  draw_glyphs (w, start_x, row, area,
  		       start, i,
! 		       DRAW_NORMAL_TEXT, overlaps);
  	}
        else
  	{
***************
*** 20659,20671 ****
  	 are redrawn.  */
        else if (hl == DRAW_NORMAL_TEXT && row->overlapped_p)
  	{
  	  if (row > w->current_matrix->rows
  	      && MATRIX_ROW_OVERLAPS_SUCC_P (row - 1))
! 	    x_fix_overlapping_area (w, row - 1, TEXT_AREA);
  
  	  if (MATRIX_ROW_BOTTOM_Y (row) < window_text_bottom_y (w)
  	      && MATRIX_ROW_OVERLAPS_PRED_P (row + 1))
! 	    x_fix_overlapping_area (w, row + 1, TEXT_AREA);
  	}
      }
  }
--- 20743,20759 ----
  	 are redrawn.  */
        else if (hl == DRAW_NORMAL_TEXT && row->overlapped_p)
  	{
+ 	  w->phys_cursor_width = x1 - w->phys_cursor.x;
+ 
  	  if (row > w->current_matrix->rows
  	      && MATRIX_ROW_OVERLAPS_SUCC_P (row - 1))
! 	    x_fix_overlapping_area (w, row - 1, TEXT_AREA,
! 				    OVERLAPS_ERASED_CURSOR);
  
  	  if (MATRIX_ROW_BOTTOM_Y (row) < window_text_bottom_y (w)
  	      && MATRIX_ROW_OVERLAPS_PRED_P (row + 1))
! 	    x_fix_overlapping_area (w, row + 1, TEXT_AREA,
! 				    OVERLAPS_ERASED_CURSOR);
  	}
      }
  }
***************
*** 22456,22468 ****
  	xassert (row->enabled_p && !row->mode_line_p);
  
  	if (row->used[LEFT_MARGIN_AREA])
! 	  x_fix_overlapping_area (w, row, LEFT_MARGIN_AREA);
  
  	if (row->used[TEXT_AREA])
! 	  x_fix_overlapping_area (w, row, TEXT_AREA);
  
  	if (row->used[RIGHT_MARGIN_AREA])
! 	  x_fix_overlapping_area (w, row, RIGHT_MARGIN_AREA);
        }
  }
  
--- 22544,22556 ----
  	xassert (row->enabled_p && !row->mode_line_p);
  
  	if (row->used[LEFT_MARGIN_AREA])
! 	  x_fix_overlapping_area (w, row, LEFT_MARGIN_AREA, OVERLAPS_BOTH);
  
  	if (row->used[TEXT_AREA])
! 	  x_fix_overlapping_area (w, row, TEXT_AREA, OVERLAPS_BOTH);
  
  	if (row->used[RIGHT_MARGIN_AREA])
! 	  x_fix_overlapping_area (w, row, RIGHT_MARGIN_AREA, OVERLAPS_BOTH);
        }
  }

Re: ATSUI support on Carbon Emacs

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> May I install this?  Such changes will be needed when we support other
> anti-aliasing environments such as Xft.

I see no problem with it -- except the the _p suffix on for_overlaps_p
should be removed, as it is no longer a simple boolean.

Pls. change that for consistency when you install your change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 06 Oct 2005 12:55:53 +0200, storm@cua.dk (Kim F. Storm) said:

>> May I install this?  Such changes will be needed when we support
>> other anti-aliasing environments such as Xft.

> I see no problem with it -- except the the _p suffix on
> for_overlaps_p should be removed, as it is no longer a simple
> boolean.

> Pls. change that for consistency when you install your change.

Thanks.  I installed it (with renaming).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Romain Francoise]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Thanks.  I installed it (with renaming).

This change breaks non-window system builds because OVERLAPS_PRED and
OVERLAPS_SUCC, used in dispnew.c, are defined in a HAVE_WINDOW_SYSTEM
conditional section in dispextern.h.

-- 
Romain Francoise <romain@orebokech.com> | The world is a fine place,
it's a miracle -- http://orebokech.com/ | and worth fighting for.
                                        | --Ernest Hemingway

Re: ATSUI support on Carbon Emacs

[Kim F. Storm]

Romain Francoise <romain@orebokech.com> writes:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>
>> Thanks.  I installed it (with renaming).
>
> This change breaks non-window system builds because OVERLAPS_PRED and
> OVERLAPS_SUCC, used in dispnew.c, are defined in a HAVE_WINDOW_SYSTEM
> conditional section in dispextern.h.

Should be fixed now.  Pls. try again.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 07 Oct 2005 23:47:55 +0200, storm@cua.dk (Kim F. Storm) said:

>> This change breaks non-window system builds because OVERLAPS_PRED
>> and OVERLAPS_SUCC, used in dispnew.c, are defined in a
>> HAVE_WINDOW_SYSTEM conditional section in dispextern.h.

> Should be fixed now.  Pls. try again.

Thanks again, and sorry for my lack of care.

Now the platform-dependent part is also installed for Mac so as to use
multiple clipping rectangles.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Romain Francoise]

storm@cua.dk (Kim F. Storm) writes:

> Should be fixed now.  Pls. try again.

Thanks.

-- 
Romain Francoise <romain@orebokech.com> | I've become someone else's
it's a miracle -- http://orebokech.com/ | nightmare...

Re: ATSUI support on Carbon Emacs

[David Reitter]

On 1 Oct 2005, at 12:28, YAMAMOTO Mitsuharu wrote:

> At the request of the maintainer, I installed ATSUI support on Carbon
> Emacs to the trunk.  It does not change anything unless -DUSE_ATSUI is
> specified at compile time.  It is still somewhat experimental, and has
> some known problems:

I think there might be another one with the font selection.

If you do set-frame-font with one of the installed fonts that show up  
in a completion buffer, you sometimes get an error:

set-frame-font: Font `-apple-frutiger-roman-medium-r-normal--0-0-0-0- 
m-0-iso10646-1' is not defined
Making completion list... [3 times]
set-frame-font: Font `-apple-frutiger-roman-medium-r-normal--0-0-0-0- 
m-0-mac-roman' is not defined

Also, the following font

-apple-helvetica ce-medium-r-normal--14-140-75-75-m-140-mac- 
centraleurroman

can't be set, instead, it just uses the default Monaco font.

Furthermore, it seems that the fonts don't exhibit the same spacing  
as in other applications. For example, a Helvetica Medium 12pt font  
is much narrower as for example in Apple Mail, where this is the  
default font (I think).
I wouldn't say that this looks bad, it's just not conforming to the  
standard.

Apart from that, I'm very grateful for ATSUI support. Variable-width  
fonts finally look good and readable. Your patch is a tremendous  
improvement.

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 11 Oct 2005 15:26:54 +0100, David Reitter <david.reitter@gmail.com> said:

> If you do set-frame-font with one of the installed fonts that show
> up in a completion buffer, you sometimes get an error:

I think this was fixed by yesterday's change.  Please test with the
latest one.

> -apple-helvetica ce-medium-r-normal--14-140-75-75-m-140-mac-centraleurroman
> can't be set, instead, it just uses the default Monaco font.

This also happens on X11.  Suppose we have

  -adobe-courier-medium-r-normal--14-140-75-75-m-90-iso10646-1
and
  -sony-fixed-medium-r-normal--16-150-75-75-c-80-iso8859-1

but not for

  -sony-fixed-medium-r-normal--16-150-75-75-c-80-iso10646-1 .

Then, 

  emacs -q -fn -adobe-courier-medium-r-normal--14-140-75-75-m-90-iso10646-1

followed by

  (set-frame-font "-sony-fixed-medium-r-normal--16-150-75-75-c-80-iso8859-1")

fails to set the second font.  If the first invocation is just "emacs
-q", then set-frame-font succeeds.

> Furthermore, it seems that the fonts don't exhibit the same spacing
> as in other applications. For example, a Helvetica Medium 12pt font
> is much narrower as for example in Apple Mail, where this is the
> default font (I think).  I wouldn't say that this looks bad, it's
> just not conforming to the standard.

I don't find much difference.  Of course, there are some differences
in integral/fractional metrics, without/with typographical features
such as kerning.  Is the difference more than those?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]


On 12 Oct 2005, at 06:03, YAMAMOTO Mitsuharu wrote:

> I don't find much difference.  Of course, there are some differences
> in integral/fractional metrics, without/with typographical features
> such as kerning.  Is the difference more than those?

No, not in terms of letter spacing. I've fallen victim to an optical  
illusion.
It's the line-spacing that makes text appear more loose in other  
apps. Take a look at these screenshots. The enlarged image shows  
Emacs on the left, and TextEdit on the right.

Also, note that the first line is glued to the tool-bar, which  
doesn't look good at all.

(This is with a version from 10-10, apologies I haven't picked up any  
changes that affect this issue.)



[-- Attachment #2: textedit-emacs-linespacing.png --]
[-- Type: image/png, Size: 10735 bytes --]

[-- Attachment #3: textedit-emacs-linespacing1.png --]
[-- Type: image/png, Size: 41864 bytes --]

[-- Attachment #4: Type: text/plain, Size: 1 bytes --]



[-- Attachment #5: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 12 Oct 2005 10:24:49 +0100, David Reitter <david.reitter@gmail.com> said:

> No, not in terms of letter spacing. I've fallen victim to an optical
> illusion.  It's the line-spacing that makes text appear more loose
> in other apps. Take a look at these screenshots. The enlarged image
> shows Emacs on the left, and TextEdit on the right.

> Also, note that the first line is glued to the tool-bar, which
> doesn't look good at all.

Hmm, I've no idea.  Two ways to calculate the line height are shown in

  http://developer.apple.com/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui_chap4/chapter_4_section_12.html

and Carbon Emacs applies the second one to the space character for
getting font ascent and descent(+leading).  I also tried some
alternatives such as the first one, the maximum value among all ASCII
characters, a metric function in ATS, and several adjustment of
parameters in ATSUI.  But all of them give essentially the same
results.  Moreover, QuickDraw Text + `SwapQDTextFlags
(kQDUseCGTextRendering | kQDUseCGTextMetrics)' also shows the same
result.  So I think it is the inherent metric for Helvetica.

Maybe Cocoa does something special?  Do you know how other Carbon
applications that use ATSUI look?

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Eli Zaretskii]

> Date: Sat, 01 Oct 2005 20:28:45 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> At the request of the maintainer, I installed ATSUI support on Carbon
> Emacs to the trunk.  It does not change anything unless -DUSE_ATSUI is
> specified at compile time.

Thank you for your work, but I think this needs to be mentioned in
NEWS (in the "Installation Changes" section).  Otherwise, there's
little chance users will find out about this feature.

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 20 Oct 2005 14:44:17 +0200, Eli Zaretskii <eliz@gnu.org> said:

>> At the request of the maintainer, I installed ATSUI support on
>> Carbon Emacs to the trunk.  It does not change anything unless
>> -DUSE_ATSUI is specified at compile time.

> Thank you for your work, but I think this needs to be mentioned in
> NEWS (in the "Installation Changes" section).  Otherwise, there's
> little chance users will find out about this feature.

I think this flag is (at least currently) for those who understand
what they are doing and especially its known problems, just like
-DSYNC_INPUT or -DSELECT_USE_CFSOCKET.  If it were for ordinary users,
then some configure option should have been added.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Eli Zaretskii]

> Date: Fri, 21 Oct 2005 10:10:13 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> > Thank you for your work, but I think this needs to be mentioned in
> > NEWS (in the "Installation Changes" section).  Otherwise, there's
> > little chance users will find out about this feature.
> 
> I think this flag is (at least currently) for those who understand
> what they are doing and especially its known problems, just like
> -DSYNC_INPUT or -DSELECT_USE_CFSOCKET.

We can add any reservations like the above near the description of
these flags, but if we don't mention them at all, how would ``those
who understand what they are doing'' learn about this option?  Do you
expect them to read the Makefile's?

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 21 Oct 2005 11:32:59 +0200, Eli Zaretskii <eliz@gnu.org> said:

>> I think this flag is (at least currently) for those who understand
>> what they are doing and especially its known problems, just like
>> -DSYNC_INPUT or -DSELECT_USE_CFSOCKET.

> We can add any reservations like the above near the description of
> these flags, but if we don't mention them at all, how would ``those
> who understand what they are doing'' learn about this option?  Do
> you expect them to read the Makefile's?

At least I'd expect them to read the thread in (possibly the archive
of) emacs-devel so that they may not report any known problems and
hopefully fix them.  I fear that it is enabled too casually.  So, how
about adding a comment like this?

/* USE_ATSUI: Enable ATSUI support.  It is still experimental and
   there are known problems.  Please refer to the thread starting from
   http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00005.html
   before enabling this flag.  */

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Eli Zaretskii]

> Date: Fri, 21 Oct 2005 18:58:42 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> /* USE_ATSUI: Enable ATSUI support.  It is still experimental and
>    there are known problems.  Please refer to the thread starting from
>    http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00005.html
>    before enabling this flag.  */

I'm okay with this, provided that it will be in NEWS, not in some C
source file.

TIA

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 21 Oct 2005 16:45:51 +0200, Eli Zaretskii <eliz@gnu.org> said:

>> Date: Fri, 21 Oct 2005 18:58:42 +0900 From: YAMAMOTO Mitsuharu
>> <mituharu@math.s.chiba-u.ac.jp> Cc: emacs-devel@gnu.org
>> 
>> /* USE_ATSUI: Enable ATSUI support.  It is still experimental and
>> there are known problems.  Please refer to the thread starting from
>> http://lists.gnu.org/archive/html/emacs-devel/2005-10/msg00005.html
>> before enabling this flag.  */

> I'm okay with this, provided that it will be in NEWS, not in some C
> source file.

I added some descriptions to mac/INSTALL.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Eli Zaretskii]

> Date: Mon, 24 Oct 2005 10:05:15 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: emacs-devel@gnu.org
> 
> I added some descriptions to mac/INSTALL.

Thanks.

Re: ATSUI support on Carbon Emacs

[Sébastien Kirche]

At 13:10 on oct 1 2005, YAMAMOTO Mitsuharu said :

> At the request of the maintainer, I installed ATSUI support on Carbon
> Emacs to the trunk.  It does not change anything unless -DUSE_ATSUI is
> specified at compile time.  It is still somewhat experimental, and has
> some known problems:

FWIW, I have found that it does not compile under OSX x86 :
/Users/seki/projets/emacs/mac/../src/macterm.c:719: error: 'Unichar' undeclared (first use in this function)
/Users/seki/projets/emacs/mac/../src/macterm.c:719: error: (Each undeclared identifier is reported only once
/Users/seki/projets/emacs/mac/../src/macterm.c:719: error: for each function it appears in.)
/Users/seki/projets/emacs/mac/../src/macterm.c:719: error: 'text' undeclared (first use in this function)
/Users/seki/projets/emacs/mac/../src/macterm.c:719: error: parse error before ')' token

In my case,  I do have USE_ATSUI and I  suppose that WORDS_BIG_ENDIAN is
not defined because of the x86 platform.

Could CarbonCore/MacTypes.h be missing ?

Regards.
-- 
Sébastien Kirche

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 25 Oct 2005 02:00:03 +0200, Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> said:

> FWIW, I have found that it does not compile under OSX x86 :
> /Users/seki/projets/emacs/mac/../src/macterm.c:719: error: 'Unichar' undeclared (first use in this function)
(snip)

> In my case, I do have USE_ATSUI and I suppose that WORDS_BIG_ENDIAN
> is not defined because of the x86 platform.

> Could CarbonCore/MacTypes.h be missing ?

No, that's just a typo.  But there's also a problem with sign
extension.  Could you try the latest one?

					YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Sébastien Kirche]

At 10:10 on oct 25 2005, YAMAMOTO Mitsuharu said :

> > Could CarbonCore/MacTypes.h be missing ?
> 
> No, that's just a typo.  But there's also a problem with sign
> extension.  Could you try the latest one?

That's ok for both UniChar  modification and the glyph selection. French
accents, euro and many others are now correctly displayed.

The only  problem that I  can see for  now is with fixed-width  font and
italics : I would say that there must be one pixel per character missing
comparing to normal ones.

Thanks.
-- 
Sébastien Kirche

Re: ATSUI support on Carbon Emacs

[Sébastien Kirche]

At 20:10 on oct 25 2005, Sébastien Kirche said :

> The only problem  that I can see for now is  with fixed-width font and
> italics  : I  would say  that there  must be  one pixel  per character
> missing comparing to normal ones.

Sorry, I realize that I am not clear. 

Italics chars are well displayed, but they seem to be one pixel narrower
that default ones  (at least the cursor is one  pixel narrower when over
an italic char).

But I suppose that you know that already.
-- 
Sébastien Kirche

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 25 Oct 2005 23:00:43 +0200, Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> said:

> Italics chars are well displayed, but they seem to be one pixel
> narrower that default ones (at least the cursor is one pixel
> narrower when over an italic char).

Which font shows the problem?  Do you see the difference in width
between default and italic ones by M-x list-face-display RET?

				    YAMAMOTO Mitsuharu
				mitharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Sébastien Kirche]

[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]

At 03:10 on oct 27 2005, YAMAMOTO Mitsuharu said :

> > > > > > On  Tue,  25  Oct  2005  23:00:43  +0200,  Sébastien  Kirche
> > > > > > <sebastien.kirche.no@spam.free.fr.invalid> said:
> 
> > Italics chars are well displayed, but they seem to be one pixel
> > narrower that default ones (at least the cursor is one pixel
> > narrower when over an italic char).
> 
> Which font shows the problem?  Do you see the difference in width
> between default and italic ones by M-x list-face-display RET?

I am currently with the default monaco.   

Plain text   uses
-apple-monaco-medium-r-normal--9-90-72-72-m-90-iso10646-1 
while italic is 
-apple-monaco-medium-i-normal--9-90-72-72-m-90-iso10646-1

I  have attached  a screenshot  where you  can see  the cursor  over the
italic 'Z'. 

(Actually,  I   noticed  that  italics   are  narrower  on   this  fresh
non-customized installation. I wonder if  it was not previously the case
with my previous non-atsui 10.3.9 powerpc configuration and I could have
customized faces  (and not  remember it) not  to use italics  because it
breaks e.g. gnus layouts. I'll check that tomorrow)...


[-- Attachment #2: Emacs x86 + ATSUI --]
[-- Type: image/png, Size: 182192 bytes --]

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]

-- 
Sébastien Kirche

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 27 Oct 2005 18:44:35 +0200, Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> said:

> I am currently with the default monaco.

> Plain text uses
> -apple-monaco-medium-r-normal--9-90-72-72-m-90-iso10646-1
> while italic is
> -apple-monaco-medium-i-normal--9-90-72-72-m-90-iso10646-1

As far as I tested on Mac OS X 10.3.9, difference in width between
default and italic could only be observed with 9pt font (as for
Monaco).  I don't think I can fix it in a non-ad hoc way.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[Sébastien Kirche]

At 12:10 on oct 28 2005, YAMAMOTO Mitsuharu said :

> > > > > > On  Thu,  27  Oct  2005  18:44:35  +0200,  Sébastien  Kirche
> > > > > > <sebastien.kirche.no@spam.free.fr.invalid> said:
> 
> > I am currently with the default monaco.
> 
> > Plain text uses
> > -apple-monaco-medium-r-normal--9-90-72-72-m-90-iso10646-1
> > while italic is
> > -apple-monaco-medium-i-normal--9-90-72-72-m-90-iso10646-1
> 


> As far as I tested on Mac OS X 10.3.9, difference in width between
> default and italic could only be observed with 9pt font (as for
> Monaco).  I don't think I can fix it in a non-ad hoc way.

Oh, so it is actually not  a problem because I was just using monaco-9pt
as the default built-in font for testing Emacs "out of the box" with x86
+ atsui support.

Instead I usually set another "developer font" that provides fixed width
chars and some details like dotted zeros to distinguish them from letter
o.

So indeed the problem with  the width of italics disappeared after using
a "defaults write" to set Emacs.font. 

One weird  detail : I had to  choose the mac-roman variant  of that font
instead of the  iso10646-1 like the default monacco.  With the iso10646,
italics  and others  styles were  ok except  bold format  that  shown no
glyphs at all (not even blank squares).

So now my display is fine, appart the current atsui imperfections. But I
find them worth to have some previously unavailable chars.

Thanks.
-- 
Sébastien Kirche

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 13 Oct 2005 17:17:18 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> But all of them give essentially the same results.  Moreover,
> QuickDraw Text + `SwapQDTextFlags (kQDUseCGTextRendering |
> kQDUseCGTextMetrics)' also shows the same result.  So I think it is
> the inherent metric for Helvetica.

> Maybe Cocoa does something special?

It actually does.  A comment in the WebKit source code says that
AppKit and WebKit make some adjustment to the heights of Courier,
Helvetica, and Times.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

I've just installed Quartz 2D drawing support code for Carbon Emacs.
It is enabled by default when -DUSE_ATSUI is specified.  It uses
Quartz 2D routines when drawing lines, rectangles, and texts, but not
for images or scroll bars.  Actually, I have some code for Quartz 2D
image drawing, but it is too much to add at this stage.

Performance measurement by Shark shows good results especially when
drawing ASCII characters with mac-allow-anti-aliasing = t.  I think
many of you who are using the experimental ATSUI-enabled version are
running Emacs under the control of gdb.  Please set a breakpoint to
fprintf so as to catch the warning message "Ignoring QuickDraw drawing
between QDBeginCGContext and QDEndCGContext", and report the backtrace
if you encounter such a situation.  Thanks.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

Because there's no objection about the patch in
http://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00901.html so
far, I'm going to enable ATSUI support at last.  Here's my plan:

  * Enable ATSUI support in Mac OS X 10.2+ by default.
    It is really slow on Mac OS X 10.1.  We don't have to worry about
    binary compatibility because Emacs built on 10.1 does not run on
    10.2+ and vice versa due to the difference about termcap/ncurses.

  * Set the default value of `mac-allow-anti-aliasing' to t for
    ATSUI-enabled environments.
    Then it can benefit from bypassing ATSUI drawing in favor of
    low-level Quartz 2D text drawing on 10.3+ for ASCII and Latin-1.

  * Update macos.texi (as below).

  * Maybe reconsider the name `mac-allow-anti-aliasing'.
    As the updated manual below says, its name is a bit different from
    what it does.  I think this is the last chance before pretesting
    if we are going to change the name.  Emacs.app for GNUstep/Cocoa
    uses `ns-use-qd-smoothing' for similar functionality.  Any ideas?

As I said in my previous post, enabling ATSUI support also activates
Quartz 2D drawing for most of drawing operations (now including
images, but this is not what I mentioned as `full alpha channel' in
http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00881.html),
though that does not change anything in appearance.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: man/macos.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/man/macos.texi,v
retrieving revision 1.28
diff -c -r1.28 macos.texi
*** man/macos.texi	9 Apr 2006 22:40:34 -0000	1.28
--- man/macos.texi	26 Apr 2006 08:26:21 -0000
***************
*** 104,116 ****
  @code{mac-roman}, @code{mac-centraleurroman}, and @code{mac-cyrillic}
  are used to represent these Mac encodings.
  
-   The fontset @code{fontset-standard} is created automatically when
- Emacs is run on Mac, and used by default.  It displays as many kinds
- of characters as possible using 12-point Monaco as a base font.  If
- you see some character as a hollow box with this fontset, then it's
- almost impossible to display it only by customizing font settings
- (@pxref{Mac Font Specs}).
- 
    You can use input methods provided either by LEIM (@pxref{Input
  Methods}) or Mac OS to enter international characters.  To use the
  former, see the International Character Set Support section of the
--- 104,109 ----
***************
*** 195,201 ****
    Command line arguments are specified like
  
  @example
! /Applications/Emacs.app/Contents/MacOS/Emacs -geometry 80x25 &
  @end example
  
  @noindent
--- 188,194 ----
    Command line arguments are specified like
  
  @example
! /Applications/Emacs.app/Contents/MacOS/Emacs -g 80x25 &
  @end example
  
  @noindent
***************
*** 295,301 ****
  Courier by customizing the default face attributes for all frames:
  
  @lisp
! (set-face-attribute 'default nil :family "courier" :height 140)
  @end lisp
  
  @noindent
--- 288,295 ----
  Courier by customizing the default face attributes for all frames:
  
  @lisp
! (set-face-attribute 'default nil
!                     :family "courier" :height 140)
  @end lisp
  
  @noindent
***************
*** 313,333 ****
  @noindent
  @xref{Font X}.  Wildcards are supported as they are on X.
  
!   Native Apple fonts in Mac Roman encoding has maker name @code{apple}
! and charset @code{mac-roman}.  For example 12-point Monaco can be
! specified by the name @samp{-apple-monaco-*-12-*-mac-roman}.  When
! using a particular size of scalable fonts, it must be specified in a
! format containing 14 @samp{-}s like
! @samp{-apple-monaco-medium-r-normal--13-*-*-*-*-*-mac-roman}.
! 
!   You can specify a @code{mac-roman} font for @acronym{ASCII}
! characters like
  
! @lisp
  (add-to-list
   'default-frame-alist
   '(font . "-apple-monaco-medium-r-normal--13-*-*-*-*-*-mac-roman"))
! @end lisp
  
  @noindent
  but that does not extend to ISO-8859-1: specifying a @code{mac-roman}
--- 307,336 ----
  @noindent
  @xref{Font X}.  Wildcards are supported as they are on X.
  
!   Emacs on Mac OS X 10.1 or former uses QuickDraw Text routines for
! drawing texts.  Emacs on Mac OS X 10.2 or later additionally uses
! @acronym{ATSUI, Apple Type Services for Unicode Imaging}, and most of
! the characters other than Chinese, Japanese, or Korean ones are drawn
! using the latter by default.
! 
!   @acronym{ATSUI}-compatible fonts have maker name @code{apple} and
! charset @code{iso10646-1}.  For example 12-point Monaco can be specified
! by the name
! @samp{-apple-monaco-medium-r-normal--12-*-*-*-*-*-iso10646-1}.  Note
! that it must be specified in a format containing 14 @samp{-}s (i.e., not
! by @samp{-apple-monaco-medium-r-normal-12-*-iso10646-1}) because every
! @acronym{ATSUI}-compatible font is a scalable one.
! 
!   QuickDraw Text fonts have maker name @code{apple} and various charset
! names other than @code{iso10646-1}.  Native Apple fonts in Mac Roman
! encoding has charset @code{mac-roman}.  You can specify a
! @code{mac-roman} font for @acronym{ASCII} characters like
  
! @smalllisp
  (add-to-list
   'default-frame-alist
   '(font . "-apple-monaco-medium-r-normal--13-*-*-*-*-*-mac-roman"))
! @end smalllisp
  
  @noindent
  but that does not extend to ISO-8859-1: specifying a @code{mac-roman}
***************
*** 341,356 ****
  @samp{mac-cyrillic}, @samp{mac-symbol}, and @samp{mac-dingbats},
  respectively.
  
-   Since Emacs as of the current version uses QuickDraw Text routines
- for drawing texts, only characters in the charsets listed above can be
- displayed with the OS-bundled fonts, even if other applications that
- use @acronym{ATSUI} or Cocoa can display variety of characters with
- them.
- 
    The use of @code{create-fontset-from-fontset-spec} (@pxref{Defining
! Fontsets}) for defining fontsets often results in wrong ones
! especially when using only OS-bundled fonts.  The recommended way is
! to create a fontset using @code{create-fontset-from-mac-roman-font}:
  
  @lisp
  (create-fontset-from-mac-roman-font
--- 344,354 ----
  @samp{mac-cyrillic}, @samp{mac-symbol}, and @samp{mac-dingbats},
  respectively.
  
    The use of @code{create-fontset-from-fontset-spec} (@pxref{Defining
! Fontsets}) for defining fontsets often results in wrong ones especially
! when using only OS-bundled QuickDraw Text fonts.  The recommended way to
! use them is to create a fontset using
! @code{create-fontset-from-mac-roman-font}:
  
  @lisp
  (create-fontset-from-mac-roman-font
***************
*** 374,384 ****
  the name @samp{-ETL-fixed-*-iso8859-1}.
  
  @vindex mac-allow-anti-aliasing
!   Emacs uses the QuickDraw text rendering by default.  On Mac OS X
! 10.2 and later, it can be changed so that it uses the Quartz 2D text
! rendering (aka CG text rendering) by setting
! @code{mac-allow-anti-aliasing} to @code{t}.  However, it is reported
! to sometimes leave some garbages.
  
  @node Mac Functions
  @section Mac-Specific Lisp Functions
--- 372,384 ----
  the name @samp{-ETL-fixed-*-iso8859-1}.
  
  @vindex mac-allow-anti-aliasing
!   Mac OS X 10.2 or later can use two types of text renderings: Quartz 2D
! (aka Core Graphics) and QuickDraw.  By default, Emacs uses the former if
! @acronym{ATSUI} is available and the latter otherwise.  It can be
! changed by setting @code{mac-allow-anti-aliasing} to @code{t} (Quartz
! 2D) or @code{nil} (QuickDraw).  Both @acronym{ATSUI} and QuickDraw Text
! drawings are affected by the value of this variable.
! 
  
  @node Mac Functions
  @section Mac-Specific Lisp Functions

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 26 Apr 2006 18:13:13 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I'm going to enable ATSUI support at last.

I forgot to tell about one thing: I'll not enable ATSUI support on the
emacs-unicode-2 branch this time for some reasons:

  * Future of the Carbon port is uncertain (I mean the switch to
    Cocoa, of course) and I doubt it's worth doing now.

  * Font handling mechanism is likely to change.
    http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-04/msg00232.html

  * Actually, there are several aspects to consider for that branch.
    My first impression that ATSUI support is easier for the
    emacs-unicode-2 branch seems to be wrong.  Some functionalities
    such as composition and font fall-back are both in emacs-unicode-2
    and in ATSUI, and they must be carefully coordinated.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: ATSUI support on Carbon Emacs

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 26 Apr 2006 18:13:13 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Because there's no objection about the patch in
> http://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00901.html
> so far, I'm going to enable ATSUI support at last.  Here's my plan:

Done, but with a few modifications as below.

>   * Enable ATSUI support in Mac OS X 10.2+ by default. 
>     It is really slow on Mac OS X 10.1.

What's slow was not ATSUI but Quartz 2D rendering.  So I enabled the
former but not the latter on Mac OS X 10.1.

>   * Maybe reconsider the name `mac-allow-anti-aliasing'.

Didn't change.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp