Patch for Mac OS X Text Drawing

Patch for Mac OS X Text Drawing

[Arthur G.P. Schuster]

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

Hello,

this is the first patch I have ever sent (and also the first time I
used Ediff), so be kind.  I found out (at
<http://developer.apple.com/qa/qa2001/qa1193.html>) how to draw text
with Quartz 2D without changing any of the old QuickDraw code.  The
advantage of Quartz is much better anti-aliasing.  And because I
desperately wanted this anti-aliasing in Emacs Carbon, I searched for
the relevant section in the code and added a few lines as suggested by
Apple.  It works on my computer (running Mac OS 10.3.7), but I have no
idea about the consequences for others, as I don't really know how
Emacs works internally.

I hope it helps to make Emacs more user-friendly on the Mac,

Arthur.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: macterm.c.diff --]
[-- Type: text/x-patch, Size: 605 bytes --]

*** /tmp/ediff5861-oC	Fri Jan 14 21:23:26 2005
--- /Users/aschus/Developer/emacs/src/macterm.c	Fri Jan 14 19:07:09 2005
***************
*** 724,729 ****
--- 724,734 ----
       char *buf;
       int nchars, mode, bytes_per_char;
  {
+ #ifdef MAC_OSX
+   UInt32 newFlags = kQDUseCGTextRendering;
+   UInt32 savedFlags = SwapQDTextFlags(newFlags);
+ #endif
+ 
    SetPortWindowPort (w);
  
    mac_set_colors (gc);
***************
*** 735,740 ****
--- 740,749 ----
  
    MoveTo (x, y);
    DrawText (buf, 0, nchars * bytes_per_char);
+ 
+ #ifdef MAC_OSX
+   SwapQDTextFlags(savedFlags);
+ #endif
  }
  
  

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

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

Re: Patch for Mac OS X Text Drawing

[Steven Tamm]

I've checked in a change that allows for anti-aliasing, but makes it 
optional (personally I only use it for large fonts).  I added the 
variable:

mac-allow-anti-aliasing

This is defaulted to nil, meaning don't use core graphics to render 
text.  When set to non-nil, (setq mac-use-core-graphics t), it will 
enable the core graphics rendering flag and will anti-alias text if 
that is enabled on your computer for the font you are trying to 
display.  I'm not a big fan of the name, because there is some basic 
anti-aliasing done in the operating system: but calling it 
mac-enable-core-graphics was too technical.

Thanks,
-Steven

On Jan 14, 2005, at 12:39 PM, Arthur G.P. Schuster wrote:

> Hello,
>
> this is the first patch I have ever sent (and also the first time I
> used Ediff), so be kind.  I found out (at
> <http://developer.apple.com/qa/qa2001/qa1193.html>) how to draw text
> with Quartz 2D without changing any of the old QuickDraw code.  The
> advantage of Quartz is much better anti-aliasing.  And because I
> desperately wanted this anti-aliasing in Emacs Carbon, I searched for
> the relevant section in the code and added a few lines as suggested by
> Apple.  It works on my computer (running Mac OS 10.3.7), but I have no
> idea about the consequences for others, as I don't really know how
> Emacs works internally.
>
> I hope it helps to make Emacs more user-friendly on the Mac,
>
> Arthur.
>
> *** /tmp/ediff5861-oC	Fri Jan 14 21:23:26 2005
> --- /Users/aschus/Developer/emacs/src/macterm.c	Fri Jan 14 19:07:09 
> 2005
> ***************
> *** 724,729 ****
> --- 724,734 ----
>        char *buf;
>        int nchars, mode, bytes_per_char;
>   {
> + #ifdef MAC_OSX
> +   UInt32 newFlags = kQDUseCGTextRendering;
> +   UInt32 savedFlags = SwapQDTextFlags(newFlags);
> + #endif
> +
>     SetPortWindowPort (w);
>
>     mac_set_colors (gc);
> ***************
> *** 735,740 ****
> --- 740,749 ----
>
>     MoveTo (x, y);
>     DrawText (buf, 0, nchars * bytes_per_char);
> +
> + #ifdef MAC_OSX
> +   SwapQDTextFlags(savedFlags);
> + #endif
>   }
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch for Mac OS X Text Drawing

[Arthur G.P. Schuster]

Steven Tamm <steventamm@mac.com> writes:

> I've checked in a change that allows for anti-aliasing, but makes it
> optional (personally I only use it for large fonts).

Thank you very much, without some background knowledge I couldn't have
created such an elegant solution.  BTW, I use ProFont at size 10 as
"default" font and Lucida Grande as "variable-pitch" font, although at
size 11 to compensate for the rather heavy ProFont.

Arthur

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 15 Jan 2005 16:39:19 -0800, Steven Tamm <steventamm@mac.com> said:

> I've checked in a change that allows for anti-aliasing, but makes it
> optional (personally I only use it for large fonts).  I added the
> variable: mac-allow-anti-aliasing

I'd prefer specifying kQDUseCGTextMetrics as in

  http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00139.html
  http://lists.gnu.org/archive/html/bug-gnu-emacs/2004-07/msg00095.html
  (Emulations of the srcCopy text transfer mode in them are no longer
   needed because a recent change obviated the use of this mode.)

because that makes bold faces have the same width as their normal
ones.  But that requires additional modifications because the metrics
are no longer compatible between two kinds of rendering engines:
QuickDraw and Quartz 2D.  One way to do such modification would be
devising XLFD foundry names as "-apple quartz2d-..." or "-apple
cg-..." (or whatever).

Maybe we need to determine the followings:

  * What do we choose?

    - Kind of rendering engines?
    - Use of anti-aliasing?
    - Or both?

  * How do we choose?

    - By compilation option?
    - By XLFD?
    - By specifying the maximum font size by a lisp variable?
    - ...

And its customization should not be too complicated.

I'd suggest two candidates:

  1. Choose the kind of rendering engines by XLFD.
     I already have a prototype for this strategy.

  2. Fix the kind of rendering engines at a compilation time (Quartz
     2D by default for >= 10.2), and control only the use of
     anti-aliasing by a lisp variable.  The variable is a list of
     pairs of a regexp and a font size.  And it overrides the system
     provided setting of the maximum font size that uses
     non-anti-aliased fonts for those that match the regexp.

I've been thinking about the former, but now I'm inclined to push the
latter.

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

Re: Patch for Mac OS X Text Drawing

[Steven Tamm]

I'd rather not invest too much in this as the whole thing should be 
replaced with ATSUI.  With emacs22 and the switch to UTF8, it'll make 
sense to redo all the font metric calculations.  I put some time into 
this, and now that I'm healthier, I'll start working on it some more.

However, adding the quick and dirty anti-aliasing seemed 
straightforward enough.  Switching over with every text call seemed 
like overkill, but I wanted to make it based on a variable.  With 
reflection it should be a frame property; that'll make the use of 
CGTextMetrics practical.

It seems odd to specify a regexp that includes font, including font 
size, and then also specify a minimum font size.  Perhaps relying on 
the system preferences (or on Silk) would be enough?

-Steven

On Jan 16, 2005, at 7:18 PM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Sat, 15 Jan 2005 16:39:19 -0800, Steven Tamm 
>>>>>> <steventamm@mac.com> said:
>
>> I've checked in a change that allows for anti-aliasing, but makes it
>> optional (personally I only use it for large fonts).  I added the
>> variable: mac-allow-anti-aliasing
>
> I'd prefer specifying kQDUseCGTextMetrics as in
>
>   http://lists.gnu.org/archive/html/emacs-devel/2003-08/msg00139.html
>   http://lists.gnu.org/archive/html/bug-gnu-emacs/2004-07/msg00095.html
>   (Emulations of the srcCopy text transfer mode in them are no longer
>    needed because a recent change obviated the use of this mode.)
>
> because that makes bold faces have the same width as their normal
> ones.  But that requires additional modifications because the metrics
> are no longer compatible between two kinds of rendering engines:
> QuickDraw and Quartz 2D.  One way to do such modification would be
> devising XLFD foundry names as "-apple quartz2d-..." or "-apple
> cg-..." (or whatever).
>
> Maybe we need to determine the followings:
>
>   * What do we choose?
>
>     - Kind of rendering engines?
>     - Use of anti-aliasing?
>     - Or both?
>
>   * How do we choose?
>
>     - By compilation option?
>     - By XLFD?
>     - By specifying the maximum font size by a lisp variable?
>     - ...
>
> And its customization should not be too complicated.
>
> I'd suggest two candidates:
>
>   1. Choose the kind of rendering engines by XLFD.
>      I already have a prototype for this strategy.
>
>   2. Fix the kind of rendering engines at a compilation time (Quartz
>      2D by default for >= 10.2), and control only the use of
>      anti-aliasing by a lisp variable.  The variable is a list of
>      pairs of a regexp and a font size.  And it overrides the system
>      provided setting of the maximum font size that uses
>      non-anti-aliased fonts for those that match the regexp.
>
> I've been thinking about the former, but now I'm inclined to push the
> latter.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 16 Jan 2005 21:31:47 -0800, Steven Tamm <steventamm@mac.com> said:

> With reflection it should be a frame property; that'll make the use
> of CGTextMetrics practical.

We need different XFontStruct (MacFontStruct) structures for the fonts
that have different metrics.  And the correspondence between a font
name and an XFontStruct structure is currently not frame-dependent
(although it is display-dependent on X11).

I don't know whether users want to use different kinds of rendering
engines per frame.

> It seems odd to specify a regexp that includes font, including font
> size, and then also specify a minimum font size.  Perhaps relying on
> the system preferences (or on Silk) would be enough?

My intention was to enable users to use information in XLFD such as
family or registry for specifying the limit of anti-aliasing.  It was
also an analogy from the variable face-font-rescale-alist.

But anyway, it turned out that my plan had a defect.  I thought about
calling SetAntiAliasedTextEnabled within every text drawing call.  But
it did not always work when Quartz 2D rendering was enabled: it worked
with "Monaco", but not with "Lucida sans typewriter".

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

Re: Patch for Mac OS X Text Drawing

[Piet van Oostrum]

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

>>>>> Steven Tamm <steventamm@mac.com> (ST) wrote:

ST> I've checked in a change that allows for anti-aliasing, but makes it
ST> optional (personally I only use it for large fonts).  I added the variable:

ST> mac-allow-anti-aliasing

ST> This is defaulted to nil, meaning don't use core graphics to render text.
ST> When set to non-nil, (setq mac-use-core-graphics t), it will enable the
Of course here you mean mac-allow-anti-alias
ST> core graphics rendering flag and will anti-alias text if that is enabled on
ST> your computer for the font you are trying to display.  I'm not a big fan of
ST> the name, because there is some basic anti-aliasing done in the operating
ST> system: but calling it mac-enable-core-graphics was too technical.

It took a few hours for me to get used to it, but now I am starting to like
it. 

I had hoped that this would solve the MacOSX bug where if you have some
italic text in a window which later is overwritten with spaces (like
happens in gnus summaries for me), small parts of the righthand side of
characters (those that stick out of the rectangular box) are not properly
erased. Also some characters are cutoff at the right. See the screen dump


[-- Attachment #2: screendump --]
[-- Type: image/png, Size: 16971 bytes --]

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


-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: piet@vanoostrum.net

[-- 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: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

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

>>>>> On Tue, 18 Jan 2005 16:40:24 +0100, Piet van Oostrum <piet@cs.uu.nl> said:

> I had hoped that this would solve the MacOSX bug where if you have
> some italic text in a window which later is overwritten with spaces
> (like happens in gnus summaries for me), small parts of the
> righthand side of characters (those that stick out of the
> rectangular box) are not properly erased. Also some characters are
> cutoff at the right.

The X11 version does handle that case.  Basically, we can also do the
same thing on Mac OS X/Carbon (try the attached patch).  But this is
not enough when used with anti-aliasing, because text drawing is no
longer idempotent: if the same text is drawn several times onto the
same place, it gets thicker.  You will notice that cursor movement
makes some characters look like in bold face as in the attached
screenshot.

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

[-- Attachment #2: screenshot.png --]
[-- Type: image/png, Size: 3302 bytes --]

[-- Attachment #3: diff-overhang-experiment.gz --]
[-- Type: application/octet-stream, Size: 1198 bytes --]

[-- 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: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 19 Jan 2005 20:48:47 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>> I had hoped that this would solve the MacOSX bug where if you have
>> some italic text in a window which later is overwritten with spaces

> The X11 version does handle that case.  Basically, we can also do
> the same thing on Mac OS X/Carbon (try the attached patch).  But
> this is not enough when used with anti-aliasing, because text
> drawing is no longer idempotent: if the same text is drawn several
> times onto the same place, it gets thicker.

The patch below works for me.  Carbon Emacs users can test it with the
previously posted macterm.c patch.  (Note that the macterm.c patch is
experimental, and only works for one-byte fonts.)

Could someone check if the following change makes sense?

				     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.192
diff -c -r1.192 dispextern.h
*** src/dispextern.h	10 Jan 2005 13:30:46 -0000	1.192
--- src/dispextern.h	21 Jan 2005 05:03:17 -0000
***************
*** 1193,1198 ****
--- 1193,1203 ----
    /* Slice */
    struct glyph_slice slice;
  
+   /* Non-null means the horizontal clipping region starts from the
+      left edge of *clip_head, and ends with the right edge of
+      *clip_tail, not including their overhangs.  */
+   struct glyph_string *clip_head, *clip_tail;
+ 
    struct glyph_string *next, *prev;
  };
  
Index: src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.966
diff -c -r1.966 xdisp.c
*** src/xdisp.c	19 Jan 2005 10:05:28 -0000	1.966
--- src/xdisp.c	21 Jan 2005 05:03:18 -0000
***************
*** 1776,1781 ****
--- 1776,1799 ----
        r.height = s->row->visible_height;
      }
  
+   if (s->clip_head)
+     if (r.x < s->clip_head->x)
+       {
+ 	if (r.width >= s->clip_head->x - r.x)
+ 	  r.width -= s->clip_head->x - r.x;
+ 	else
+ 	  r.width = 0;
+ 	r.x = s->clip_head->x;
+       }
+   if (s->clip_tail)
+     if (r.x + r.width > s->clip_tail->x + s->clip_tail->width)
+       {
+ 	if (s->clip_tail->x + s->clip_tail->width >= r.x)
+ 	  r.width = s->clip_tail->x + s->clip_tail->width - r.x;
+ 	else
+ 	  r.width = 0;
+       }
+ 
    /* If S draws overlapping rows, it's sufficient to use the top and
       bottom of the window for clipping because this glyph string
       intentionally draws over other lines.  */
***************
*** 18269,18274 ****
--- 18287,18293 ----
      {
        int dummy_x = 0;
        struct glyph_string *h, *t;
+       struct glyph_string *clip_head = NULL, *clip_tail = NULL;
  
        /* Compute overhangs for all glyph strings.  */
        if (rif->compute_glyph_string_overhangs)
***************
*** 18289,18294 ****
--- 18308,18314 ----
  	  start = i;
  	  compute_overhangs_and_x (t, head->x, 1);
  	  prepend_glyph_string_lists (&head, &tail, h, t);
+ 	  clip_head = head;
  	}
  
        /* Prepend glyph strings for glyphs in front of the first glyph
***************
*** 18301,18306 ****
--- 18321,18327 ----
        i = left_overwriting (head);
        if (i >= 0)
  	{
+ 	  clip_head = head;
  	  BUILD_GLYPH_STRINGS (i, start, h, t,
  			       DRAW_NORMAL_TEXT, dummy_x, last_x);
  	  for (s = h; s; s = s->next)
***************
*** 18320,18325 ****
--- 18341,18347 ----
  			       DRAW_NORMAL_TEXT, x, last_x);
  	  compute_overhangs_and_x (h, tail->x + tail->width, 0);
  	  append_glyph_string_lists (&head, &tail, h, t);
+ 	  clip_tail = tail;
  	}
  
        /* Append glyph strings for glyphs following the last glyph
***************
*** 18330,18335 ****
--- 18352,18358 ----
        i = right_overwriting (tail);
        if (i >= 0)
  	{
+ 	  clip_tail = tail;
  	  BUILD_GLYPH_STRINGS (end, i, h, t,
  			       DRAW_NORMAL_TEXT, x, last_x);
  	  for (s = h; s; s = s->next)
***************
*** 18337,18342 ****
--- 18360,18371 ----
  	  compute_overhangs_and_x (h, tail->x + tail->width, 0);
  	  append_glyph_string_lists (&head, &tail, h, t);
  	}
+       if (clip_head || clip_tail)
+ 	for (s = head; s; s = s->next)
+ 	  {
+ 	    s->clip_head = clip_head;
+ 	    s->clip_tail = clip_tail;
+ 	  }
      }
  
    /* Draw all strings.  */

Re: Patch for Mac OS X Text Drawing

[Richard Stallman]

It seems strange that a Mac-only bug would need system-independent changes.
Why is that?

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 21 Jan 2005 21:52:55 -0500, Richard Stallman <rms@gnu.org> said:

> It seems strange that a Mac-only bug would need system-independent
> changes.  Why is that?

Because the current (system-independent) code assumes that drawing the
same character over the existing one does not change its appearance,
but that's not true on Mac OS X with text anti-aliasing.

Quote from http://developer.apple.com/qa/qa2001/qa1193.html:

  Avoid double-drawing the same text because anti-aliased areas darken
  with repeated over-drawing.

I'm not sure about other environments with anti-aliasing such as Xft
and ClearType.  Does anyone know about how over-drawing is treated
there?

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

Re: Patch for Mac OS X Text Drawing

[Kenichi Handa]

In article <20050122.124732.63490425.mituharu@math.s.chiba-u.ac.jp>, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> Because the current (system-independent) code assumes that drawing the
> same character over the existing one does not change its appearance,
> but that's not true on Mac OS X with text anti-aliasing.

> Quote from http://developer.apple.com/qa/qa2001/qa1193.html:

>   Avoid double-drawing the same text because anti-aliased areas darken
>   with repeated over-drawing.

> I'm not sure about other environments with anti-aliasing such as Xft
> and ClearType.  Does anyone know about how over-drawing is treated
> there?

The tutorial of Xft says to clear or fill an area before
drawing a text there as below:

------------------------------------------------------------
5.3 Text Drawing

Xft doesn't support "image text" at all; rather the application must
explicitly fill the background rectangle before drawing the string.  With AA
text, there's no other way to make it work.

	XDrawString 		-> XftDrawString8
	XDrawImageString	-> XftDrawRect + XftDrawString8

Note that drawing the same string multiple times in the same place will
generate the wrong result with AA text.  This can be especially hard to fix
in applications that avoid setting clipping when redrawing parts of
windows.  An easy fix here is to simply clear the entire window before
redrawing it.  This does cause extensive flashing on the screen, the
alternative is to use clipping and make sure that any areas within the clip
region get cleared to the background before text is drawn on top.
------------------------------------------------------------

---
Ken'ichi HANDA
handa@m17n.org

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 22 Jan 2005 13:55:46 +0900 (JST), Kenichi Handa <handa@m17n.org> said:

>> I'm not sure about other environments with anti-aliasing such as
>> Xft and ClearType.  Does anyone know about how over-drawing is
>> treated there?

> The tutorial of Xft says to clear or fill an area before drawing a
> text there as below:

> 5.3 Text Drawing

> Note that drawing the same string multiple times in the same place
> will generate the wrong result with AA text.

Thanks for the info.  The situation in Xft seems to be quite similar.

> the alternative is to use clipping and make sure that any areas
> within the clip region get cleared to the background before text is
> drawn on top.

The above sentence exactly explains what I intended by the patch.

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

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 21 Jan 2005 16:57:51 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> Could someone check if the following change makes sense?

It turned out that the posted patch was closely related to the
following problem (also on X11), which I've reported to
emacs-pretest-bug:

>>>>> On Fri, 21 Jan 2005 12:53:37 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> I noticed that the cursor remained unerased with the following
> procedure:

> 1. % emacs -Q -fn -adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1 & 
> 2. Type "RET C-p W C-b W W W W ...."

> This happens with any cursor type.

Here is a revised patch including a fix for the above bug.

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

Index: src/dispextern.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/dispextern.h,v
retrieving revision 1.192
diff -c -r1.192 dispextern.h
*** src/dispextern.h	10 Jan 2005 13:30:46 -0000	1.192
--- src/dispextern.h	24 Jan 2005 08:42:45 -0000
***************
*** 1193,1198 ****
--- 1193,1203 ----
    /* Slice */
    struct glyph_slice slice;
  
+   /* Non-null means the horizontal clipping region starts from the
+      left edge of *clip_head, and ends with the right edge of
+      *clip_tail, not including their overhangs.  */
+   struct glyph_string *clip_head, *clip_tail;
+ 
    struct glyph_string *next, *prev;
  };
  
Index: src/xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.969
diff -c -r1.969 xdisp.c
*** src/xdisp.c	23 Jan 2005 00:50:52 -0000	1.969
--- src/xdisp.c	24 Jan 2005 08:42:47 -0000
***************
*** 1786,1791 ****
--- 1786,1809 ----
        r.height = s->row->visible_height;
      }
  
+   if (s->clip_head)
+     if (r.x < s->clip_head->x)
+       {
+ 	if (r.width >= s->clip_head->x - r.x)
+ 	  r.width -= s->clip_head->x - r.x;
+ 	else
+ 	  r.width = 0;
+ 	r.x = s->clip_head->x;
+       }
+   if (s->clip_tail)
+     if (r.x + r.width > s->clip_tail->x + s->clip_tail->background_width)
+       {
+ 	if (s->clip_tail->x + s->clip_tail->background_width >= r.x)
+ 	  r.width = s->clip_tail->x + s->clip_tail->background_width - r.x;
+ 	else
+ 	  r.width = 0;
+       }
+ 
    /* If S draws overlapping rows, it's sufficient to use the top and
       bottom of the window for clipping because this glyph string
       intentionally draws over other lines.  */
***************
*** 18231,18236 ****
--- 18249,18255 ----
  {
    struct glyph_string *head, *tail;
    struct glyph_string *s;
+   struct glyph_string *clip_head = NULL, *clip_tail = NULL;
    int last_x, area_width;
    int x_reached;
    int i, j;
***************
*** 18299,18304 ****
--- 18318,18324 ----
  	  start = i;
  	  compute_overhangs_and_x (t, head->x, 1);
  	  prepend_glyph_string_lists (&head, &tail, h, t);
+ 	  clip_head = head;
  	}
  
        /* Prepend glyph strings for glyphs in front of the first glyph
***************
*** 18311,18316 ****
--- 18331,18337 ----
        i = left_overwriting (head);
        if (i >= 0)
  	{
+ 	  clip_head = head;
  	  BUILD_GLYPH_STRINGS (i, start, h, t,
  			       DRAW_NORMAL_TEXT, dummy_x, last_x);
  	  for (s = h; s; s = s->next)
***************
*** 18330,18335 ****
--- 18351,18357 ----
  			       DRAW_NORMAL_TEXT, x, last_x);
  	  compute_overhangs_and_x (h, tail->x + tail->width, 0);
  	  append_glyph_string_lists (&head, &tail, h, t);
+ 	  clip_tail = tail;
  	}
  
        /* Append glyph strings for glyphs following the last glyph
***************
*** 18340,18345 ****
--- 18362,18368 ----
        i = right_overwriting (tail);
        if (i >= 0)
  	{
+ 	  clip_tail = tail;
  	  BUILD_GLYPH_STRINGS (end, i, h, t,
  			       DRAW_NORMAL_TEXT, x, last_x);
  	  for (s = h; s; s = s->next)
***************
*** 18347,18352 ****
--- 18370,18381 ----
  	  compute_overhangs_and_x (h, tail->x + tail->width, 0);
  	  append_glyph_string_lists (&head, &tail, h, t);
  	}
+       if (clip_head || clip_tail)
+ 	for (s = head; s; s = s->next)
+ 	  {
+ 	    s->clip_head = clip_head;
+ 	    s->clip_tail = clip_tail;
+ 	  }
      }
  
    /* Draw all strings.  */
***************
*** 18360,18367 ****
  	 completely. */
        && !overlaps_p)
      {
!       int x0 = head ? head->x : x;
!       int x1 = tail ? tail->x + tail->background_width : x;
  
        int text_left = window_box_left (w, TEXT_AREA);
        x0 -= text_left;
--- 18389,18397 ----
  	 completely. */
        && !overlaps_p)
      {
!       int x0 = clip_head ? clip_head->x : (head ? head->x : x);
!       int x1 = (clip_tail ? clip_tail->x + clip_tail->background_width
! 		: (tail ? tail->x + tail->background_width : x));
  
        int text_left = window_box_left (w, TEXT_AREA);
        x0 -= text_left;

Re: Patch for Mac OS X Text Drawing

[Kim F. Storm]

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

>>>>>> On Fri, 21 Jan 2005 16:57:51 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>
>> Could someone check if the following change makes sense?
>
> It turned out that the posted patch was closely related to the
> following problem (also on X11), which I've reported to
> emacs-pretest-bug:
>
>>>>>> On Fri, 21 Jan 2005 12:53:37 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:
>
>> I noticed that the cursor remained unerased with the following
>> procedure:
>
>> 1. % emacs -Q -fn -adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1 & 
>> 2. Type "RET C-p W C-b W W W W ...."
>
>> This happens with any cursor type.
>
> Here is a revised patch including a fix for the above bug.

Very good, thanks!  Please install it.

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

Re: Patch for Mac OS X Text Drawing

[YAMAMOTO Mitsuharu]

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

>>>>> On Mon, 24 Jan 2005 11:08:02 +0100, storm@cua.dk (Kim F. Storm) said:

>> Here is a revised patch including a fix for the above bug.

> Very good, thanks!  Please install it.

Thanks for checking.  I'd like to leave it to Steven because the whole
patch (attached below) includes some changes for Mac.  Actually, I
cannot do it by myself at the moment.

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

2005-01-24  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>

	* dispextern.h (struct glyph_string): New members clip_head and
	clip_tail.
	
	* xdisp.c (get_glyph_string_clip_rect): Restrict horizontal clip
	region to the area between clip_head and clip_tail.
	(draw_glyphs): Record the area that need to be actually redrawn to
	the new variables clip_head and clip_tail when there are
	overhangs.  Set values of these variables to the corresponding
	members in struct glyph_string.  Refine x coordinates for
	notice_overwritten_cursor using clip_head and clip_tail.
	
	* macgui.h (STORE_XCHARSETSTRUCT): New macro.

	* macterm.c (mac_compute_glyph_string_overhangs): Implement with
	QDTextBounds.
	(x_draw_glyph_string): Don't fill the background of the successor
	of a glyph with a right overhang if the successor will draw a
	cursor.
	(XLoadQueryFont): Obtain font metrics using QDTextBounds.
	(x_redisplay_interface): Add entry for
	compute_glyph_string_overhangs.


[-- Attachment #2: diff-overhangs.gz --]
[-- Type: application/octet-stream, Size: 3143 bytes --]

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

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

Re: Patch for Mac OS X Text Drawing

[Steven Tamm]

I checked this in.
Although I think it may make sense to grant CVS access to Mr. Yamamoto, 
as the patches are now going outside the domain of just Mac/Carbon and 
into the whole realm of display rendering on all platforms.

-Steven

On Jan 24, 2005, at 3:15 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Mon, 24 Jan 2005 11:08:02 +0100, storm@cua.dk (Kim F. Storm) 
>>>>>> said:
>
>>> Here is a revised patch including a fix for the above bug.
>
>> Very good, thanks!  Please install it.
>
> Thanks for checking.  I'd like to leave it to Steven because the whole
> patch (attached below) includes some changes for Mac.  Actually, I
> cannot do it by myself at the moment.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
> 2005-01-24  YAMAMOTO Mitsuharu  <mituharu@math.s.chiba-u.ac.jp>
>
> 	* dispextern.h (struct glyph_string): New members clip_head and
> 	clip_tail.
> 	
> 	* xdisp.c (get_glyph_string_clip_rect): Restrict horizontal clip
> 	region to the area between clip_head and clip_tail.
> 	(draw_glyphs): Record the area that need to be actually redrawn to
> 	the new variables clip_head and clip_tail when there are
> 	overhangs.  Set values of these variables to the corresponding
> 	members in struct glyph_string.  Refine x coordinates for
> 	notice_overwritten_cursor using clip_head and clip_tail.
> 	
> 	* macgui.h (STORE_XCHARSETSTRUCT): New macro.
>
> 	* macterm.c (mac_compute_glyph_string_overhangs): Implement with
> 	QDTextBounds.
> 	(x_draw_glyph_string): Don't fill the background of the successor
> 	of a glyph with a right overhang if the successor will draw a
> 	cursor.
> 	(XLoadQueryFont): Obtain font metrics using QDTextBounds.
> 	(x_redisplay_interface): Add entry for
> 	compute_glyph_string_overhangs.
>
> <diff-overhangs.gz>_______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel