all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* antialiasing for emacs
@ 2003-07-24 20:37 Chris Gray
  2003-07-25  2:02 ` Miles Bader
  2003-07-27  4:28 ` Marcelo Toledo
  0 siblings, 2 replies; 10+ messages in thread
From: Chris Gray @ 2003-07-24 20:37 UTC (permalink / raw)



Hi,

I have put together antialiasing support for GNU emacs on X.  At this
point it is pretty slow[1] and there seem to be a couple of bugs still
left to work out (starting gnus and info both cause bad things to
happen).  However, in the spirit of "release early and often", the
code is attached.  

I have not yet added the appropriate tests to configure.in and the
Makefile needs to be modified appropriately if you want to test this
out.  

Cheers,
Chris

[1] The slowness is because I can't trust the attributes of a face not
to change.  If there was a different face for the cursor than the rest
of the text (instead of simply changing the GC), the story would be
different. 



===File ~/src/emacs/src/emacs.diff==========================
? emacs.diff
Index: dispextern.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/dispextern.h,v
retrieving revision 1.153
diff -u -r1.153 dispextern.h
--- dispextern.h	24 May 2003 21:56:19 -0000	1.153
+++ dispextern.h	23 Jul 2003 02:07:19 -0000
@@ -31,6 +31,11 @@
 #include <X11/Intrinsic.h>
 #endif /* USE_X_TOOLKIT */
 
+#define HAVE_XFT
+#ifdef HAVE_XFT
+#include <X11/Xft/Xft.h>
+#endif
+
 #else /* !HAVE_X_WINDOWS */
 
 /* X-related stuff used by non-X gui code. */
@@ -1330,6 +1335,13 @@
   /* Background stipple or bitmap used for this face.  This is
      an id as returned from load_pixmap.  */
   int stipple;
+
+#ifdef HAVE_XFT
+  XftFont *xftfont;
+  XftColor xftforeground;
+  XftColor xftbackground;
+  XftDraw *draw;
+#endif
 
 #else /* not HAVE_WINDOW_SYSTEM */
 
Index: xfaces.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xfaces.c,v
retrieving revision 1.281
diff -u -r1.281 xfaces.c
--- xfaces.c	26 Jun 2003 21:18:45 -0000	1.281
+++ xfaces.c	23 Jul 2003 02:07:26 -0000
@@ -5094,6 +5094,51 @@
       face->gc = x_create_gc (f, mask, &xgcv);
       UNBLOCK_INPUT;
     }
+#ifdef HAVE_XFT
+  //  BLOCK_INPUT;
+  if (face->draw == 0)
+    {	
+      XWindowAttributes atts;
+      XGetWindowAttributes (FRAME_X_DISPLAY(f), FRAME_X_WINDOW(f), &atts);
+      face->draw = XftDrawCreate (FRAME_X_DISPLAY(f), 
+				 (Drawable) FRAME_X_WINDOW(f), 
+				 atts.visual, atts.colormap);
+    }
+  if (face->font != 0 && face->xftfont == 0)
+    {
+      char *name;
+      XFontStruct *fs = face->font;
+      Atom value;
+      XGetFontProperty (fs, XA_FONT, &value);
+      name = (char *) XGetAtomName(FRAME_X_DISPLAY (f), value);
+      //XFree (fs);
+
+      face->xftfont = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen(FRAME_X_DISPLAY(f)), name);
+      xassert(face->xftfont);
+      XFree (name);
+    }
+  {
+    XWindowAttributes atts;
+    XColor newcolor;
+    XGetWindowAttributes (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f), &atts);
+    face->xftforeground.pixel = face->foreground;
+    newcolor.pixel = face->foreground;
+    XQueryColor (FRAME_X_DISPLAY (f), atts.colormap, &newcolor);
+    face->xftforeground.color.red = newcolor.red;
+    face->xftforeground.color.green = newcolor.green;
+    face->xftforeground.color.blue = newcolor.blue;
+    face->xftforeground.color.alpha = 0xffff;
+    face->xftbackground.pixel = face->background;
+    newcolor.pixel = face->background;
+    XQueryColor (FRAME_X_DISPLAY (f), atts.colormap, &newcolor);
+    face->xftbackground.color.red = newcolor.red;
+    face->xftbackground.color.green = newcolor.green;
+    face->xftbackground.color.blue = newcolor.blue;
+    face->xftbackground.color.alpha = 0xffff;
+  }
+  // UNBLOCK_INPUT;
+
+#endif /* HAVE_XFT */
 #endif /* HAVE_WINDOW_SYSTEM */
 }
 
@@ -6784,6 +6829,9 @@
     {
       bcopy (base_face, face, sizeof *face);
       face->gc = 0;
+#ifdef HAVE_XFT
+      face->xftfont = 0;
+#endif
 
       /* Don't try to free the colors copied bitwise from BASE_FACE.  */
       face->colors_copied_bitwise_p = 1;
Index: xterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xterm.c,v
retrieving revision 1.802
diff -u -r1.802 xterm.c
--- xterm.c	17 Jul 2003 10:15:04 -0000	1.802
+++ xterm.c	23 Jul 2003 02:07:30 -0000
@@ -183,6 +183,12 @@
 
 int x_use_underline_position_properties;
 
+#ifdef HAVE_XFT
+/* Non-zero means use Xft for anti-aliased fonts */
+
+int x_use_xft;
+#endif
+
 /* This is a chain of structures for all the X displays currently in
    use.  */
 
@@ -1200,6 +1206,55 @@
     }
 }
 
+#ifdef HAVE_XFT
+
+/* Get the colors from the graphics context so that
+   we can render the xft colors correctly (without changing
+   too much old code).
+
+   FIXME: pretty much unnecessary if we are only going to be
+   using Xft.
+ */
+
+static void
+x_get_colors_from_gc (s, fgcolor, bgcolor)
+     struct glyph_string *s;
+     XftColor *fgcolor;
+     XftColor *bgcolor;
+{
+  GC gc = s->gc;
+  Drawable d = FRAME_X_WINDOW(s->f);
+  XGCValues vals;
+  XWindowAttributes info;
+
+  XGetWindowAttributes(FRAME_X_DISPLAY(s->f), (Window) d, &info);
+  XGetGCValues(FRAME_X_DISPLAY(s->f), gc, GCBackground | GCForeground, &vals);
+
+  if (fgcolor) 
+    {
+      XColor newcolor;
+      fgcolor->pixel = vals.foreground;
+      newcolor.pixel = vals.foreground;
+      XQueryColor(FRAME_X_DISPLAY(s->f), info.colormap, &newcolor);
+      fgcolor->color.red = newcolor.red;
+      fgcolor->color.green = newcolor.green;
+      fgcolor->color.blue = newcolor.blue;
+      fgcolor->color.alpha = 0xffff;
+    }
+  if (bgcolor) 
+    {
+      XColor newcolor;
+      bgcolor->pixel = vals.background;
+      newcolor.pixel = vals.background;
+      XQueryColor(FRAME_X_DISPLAY(s->f), info.colormap, &newcolor);
+      bgcolor->color.red = newcolor.red;
+      bgcolor->color.blue = newcolor.blue;
+      bgcolor->color.green = newcolor.green;
+      bgcolor->color.alpha = 0xffff;
+    }
+}
+
+#endif
 
 /* Draw the foreground of glyph string S.  */
 
@@ -1251,22 +1306,75 @@
       if (s->for_overlaps_p
 	  || (s->background_filled_p && s->hl != DRAW_CURSOR))
 	{
+#ifndef HAVE_XFT
+#define HAVE_XFT_VAL 0
+#else
+#define HAVE_XFT_VAL 1
+#endif
+	  if (!x_use_xft || !(HAVE_XFT_VAL)) 
+	    {
 	  /* Draw characters with 16-bit or 8-bit functions.  */
-	  if (s->two_byte_p)
-	    XDrawString16 (s->display, s->window, s->gc, x,
-			   s->ybase - boff, s->char2b, s->nchars);
-	  else
-	    XDrawString (s->display, s->window, s->gc, x,
-			 s->ybase - boff, char1b, s->nchars);
+	      if (s->two_byte_p)
+		XDrawString16 (s->display, s->window, s->gc, x,
+			       s->ybase - boff, s->char2b, s->nchars);
+	      else
+		XDrawString (s->display, s->window, s->gc, x,
+			     s->ybase - boff, char1b, s->nchars);
+	    }
+	  else 
+	    {
+#ifdef HAVE_XFT
+	      XftColor foreground;
+	      
+	      x_get_colors_from_gc (s, &foreground, NULL);
+	      if (s->two_byte_p) 
+		XftDrawString16 (s->face->draw, &foreground, s->face->xftfont, x, s->ybase, (unsigned short *) s->char2b, s->nchars);
+	      else
+		XftDrawString8 (s->face->draw, &foreground, s->face->xftfont, x, s->ybase, char1b, s->nchars);
+#endif
+	    }
 	}
       else
 	{
-	  if (s->two_byte_p)
-	    XDrawImageString16 (s->display, s->window, s->gc, x,
-				s->ybase - boff, s->char2b, s->nchars);
-	  else
-	    XDrawImageString (s->display, s->window, s->gc, x,
-			      s->ybase - boff, char1b, s->nchars);
+	  if (!x_use_xft || !(HAVE_XFT_VAL))
+	    {
+	      if (s->two_byte_p)
+		XDrawImageString16 (s->display, s->window, s->gc, x,
+				    s->ybase - boff, s->char2b, s->nchars);
+	      else
+		XDrawImageString (s->display, s->window, s->gc, x,
+				  s->ybase - boff, char1b, s->nchars);
+	    }
+	  else 
+	    {
+#ifdef HAVE_XFT
+	      XftColor foreground, background;
+
+	      x_get_colors_from_gc (s, &foreground, &background);
+	      if (s->two_byte_p)
+		{
+		  int width, height;
+		  XGlyphInfo extents;
+		  XftTextExtents16 (s->display, s->face->xftfont, (unsigned short *) s->char2b, s->nchars, &extents);
+		  width = extents.xOff;
+		  height = s->face->xftfont->ascent + s->face->xftfont->descent;
+
+		  XftDrawRect (s->face->draw, &background, x, s->ybase - s->face->xftfont->ascent, width, height);
+		  XftDrawString16 (s->face->draw, &foreground, s->face->xftfont, x, s->ybase, (unsigned short *) s->char2b, s->nchars);
+		}
+	      else 
+		{
+		  int width, height;
+		  XGlyphInfo extents;
+		  XftTextExtents8 (s->display, s->face->xftfont, char1b, s->nchars, &extents);
+		  width = extents.xOff;
+		  height = s->face->xftfont->ascent + s->face->xftfont->descent - 3;
+
+		  XftDrawRect (s->face->draw, &background, x, s->ybase + 2 - s->face->xftfont->ascent, width, height);
+		  XftDrawString8 (s->face->draw, &foreground, s->face->xftfont, x, s->ybase, char1b, s->nchars);
+		}
+#endif
+	    }
 	}
 
       if (s->face->overstrike)
@@ -10810,6 +10918,12 @@
 UNDERLINE_POSITION font properties, for example 7x13 on XFree prior
 to 4.1, set this to nil.  */);
   x_use_underline_position_properties = 1;
+
+#ifdef HAVE_XFT
+  DEFVAR_BOOL ("x-use-xft", &x_use_xft,
+	       doc: /* *Non-nil means to use Xft for anti-aliasing */);
+  x_use_xft = 1;
+#endif
 
   DEFVAR_LISP ("x-toolkit-scroll-bars", &Vx_toolkit_scroll_bars,
     doc: /* What X toolkit scroll bars Emacs uses.
============================================================

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-24 20:37 antialiasing for emacs Chris Gray
@ 2003-07-25  2:02 ` Miles Bader
  2003-07-25 19:07   ` Chris Gray
  2003-07-27  4:28 ` Marcelo Toledo
  1 sibling, 1 reply; 10+ messages in thread
From: Miles Bader @ 2003-07-25  2:02 UTC (permalink / raw)


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

Hi, I tried your patch, which seemed to work very well at first -- my
normal emacs fonts were indeed anti-aliased, and looked very nice.  The
patch seems impressively small.

I had to use the following extra patch to get things to compile on my
system (Debian unstable), apparently due to bogosities in <png.h>.
I'm not sure why your change tickled it; maybe due to including <Xft.h>
in dispextern.h.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Patch to include <png.h> before emacs-specific includes --]
[-- Type: text/x-patch, Size: 673 bytes --]

--- src/xfns.c.~1.587.~	2003-07-23 09:51:51.000000000 +0900
+++ src/xfns.c	2003-07-25 10:45:32.000000000 +0900
@@ -28,6 +28,14 @@ Boston, MA 02111-1307, USA.  */
 #include <unistd.h>
 #endif
 
+#ifdef HAVE_PNG
+# if defined HAVE_LIBPNG_PNG_H
+#  include <libpng/png.h>
+# else
+#  include <png.h>
+# endif
+#endif /* HAVE_PNG */
+
 /* This makes the fields of a Display accessible, in Xlib header files.  */
 
 #define XLIB_ILLEGAL_ACCESS
@@ -7565,12 +7573,6 @@ pbm_load (f, img)
 
 #if HAVE_PNG
 
-#if defined HAVE_LIBPNG_PNG_H
-# include <libpng/png.h>
-#else
-# include <png.h>
-#endif
-
 /* Function prototypes.  */
 
 static int png_image_p P_ ((Lisp_Object object));

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




When I tried to go into info (which uses a fair number of fonts), emacs
hung, with an error on standard output like:

   Xlib: unexpected async reply (sequence 0x1248)!

I then tried to start emacs with a more standard configuration, and
_that_ made it hang immediately with a similar error message:

   (emacs) xrdb -remove
   (emacs) src/emacs -q -fn -*-courier-medium-r-*--12-*-*-*-*-*-iso8859-1
   Xlib: unexpected async reply (sequence 0x545)!

[I had to use the `-fn' option because the standard font emacs uses
doesn't seem to exist on my system!]

I guess this must be one of the small bugs you were talking about... :-)

> [1] The slowness is because I can't trust the attributes of a face not
> to change.  If there was a different face for the cursor than the rest
> of the text (instead of simply changing the GC), the story would be
> different. 

I'm confused by this -- isn't there a separate face for the cursor (`cursor')?

-miles
-- 
If you can't beat them, arrange to have them beaten.  [George Carlin]

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

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-25  2:02 ` Miles Bader
@ 2003-07-25 19:07   ` Chris Gray
  2003-07-27 22:33     ` Miles Bader
  0 siblings, 1 reply; 10+ messages in thread
From: Chris Gray @ 2003-07-25 19:07 UTC (permalink / raw)
  Cc: emacs-devel

On Fri, 25 Jul 2003, Miles Bader wrote:
> [...description of the bug...]
> 
> I guess this must be one of the small bugs you were talking
> about... :-)

Yep.  It happens when I start gnus too.  I really don't know why, and
these "async errors" seem very hard to debug.

>> [1] The slowness is because I can't trust the attributes of a face
>> not to change.  If there was a different face for the cursor than
>> the rest of the text (instead of simply changing the GC), the story
>> would be different.
> 
> I'm confused by this -- isn't there a separate face for the cursor
> (`cursor')?

Well if there is, it's not getting used.  You'll notice in xterm.c,
there is a function called x_set_cursor_gc, which pretty much ignores
the face information.

Cheers,
Chris

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-24 20:37 antialiasing for emacs Chris Gray
  2003-07-25  2:02 ` Miles Bader
@ 2003-07-27  4:28 ` Marcelo Toledo
  1 sibling, 0 replies; 10+ messages in thread
From: Marcelo Toledo @ 2003-07-27  4:28 UTC (permalink / raw)


I just tested your patch and for the first one I think it worked pretty
well, but async reply is a problem.

I've took a few screenshots:

http://www.marcelotoledo.org/stuff.php?c=m&t=DIR&f=/stuff/screenshots/emacs21_antialiased

what I tested and failed:

toolbar, display, other fonts, tetris and simlar, gnus smileys, emacs
-q.

I was reading the source of Xft and I just dont understend why each
family of font has your own header and functions, all functions always
worked (including truetype) with the conventional headers, metrics and
functions. The scalable font model of X is above type-1, which is totaly
equal to truetype metrics. There is no sense xfree making this Xft.

Chris Gray <cmg@cs.ubc.ca> writes:

> Hi,
>
> I have put together antialiasing support for GNU emacs on X.  At this
> point it is pretty slow[1] and there seem to be a couple of bugs still
> left to work out (starting gnus and info both cause bad things to
> happen).  However, in the spirit of "release early and often", the
> code is attached.  

-- 
Marcelo Toledo
marcelo@marcelotoledo.org
http://www.marcelotoledo.org
Mobile: 55 71 9141-7181

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-25 19:07   ` Chris Gray
@ 2003-07-27 22:33     ` Miles Bader
  2003-07-28 20:04       ` Stefan Monnier
  0 siblings, 1 reply; 10+ messages in thread
From: Miles Bader @ 2003-07-27 22:33 UTC (permalink / raw)


Chris Gray <christopher.gray@mail.mcgill.ca> writes:
> Yep.  It happens when I start gnus too.  I really don't know why, and
> these "async errors" seem very hard to debug.

Hmmm, actually, come to think of it, there's a function to make emacs
use X `synchronously', which might make debugging easier...

   x-synchronize is a built-in function.
   (x-synchronize ON &optional DISPLAY)

   If ON is non-nil, report errors as soon as the erring request is made.
   If ON is nil, allow buffering of requests.
   This is a noop on Mac OS systems.
   The optional second argument DISPLAY specifies which display to act on.
   DISPLAY should be either a frame or a display name (a string).
   If DISPLAY is omitted or nil, that stands for the selected frame's display.

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-27 22:33     ` Miles Bader
@ 2003-07-28 20:04       ` Stefan Monnier
  2003-07-28 20:22         ` Chris Gray
  2003-07-30 20:31         ` Richard Stallman
  0 siblings, 2 replies; 10+ messages in thread
From: Stefan Monnier @ 2003-07-28 20:04 UTC (permalink / raw)
  Cc: emacs-devel

> Chris Gray <christopher.gray@mail.mcgill.ca> writes:
> > Yep.  It happens when I start gnus too.  I really don't know why, and
> > these "async errors" seem very hard to debug.
> 
> Hmmm, actually, come to think of it, there's a function to make emacs
> use X `synchronously', which might make debugging easier...
> 
>    x-synchronize is a built-in function.
>    (x-synchronize ON &optional DISPLAY)
> 
>    If ON is non-nil, report errors as soon as the erring request is made.
>    If ON is nil, allow buffering of requests.
>    This is a noop on Mac OS systems.
>    The optional second argument DISPLAY specifies which display to act on.
>    DISPLAY should be either a frame or a display name (a string).
>    If DISPLAY is omitted or nil, that stands for the selected frame's display.
> 
> -Miles

I don't think it's going to help.  The `async error' is generally
due to missing BLOCK_INPUT statements that lead to Xlib functions
being called from the signal handler while we're already inside
an Xlib function.

My patch that makes the signal handler trivial (and handles "async"
signals from the QUIT macro instead) should solve this problem once and
for all.


	Stefan

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-28 20:04       ` Stefan Monnier
@ 2003-07-28 20:22         ` Chris Gray
  2003-08-13 10:48           ` Miles Bader
  2003-07-30 20:31         ` Richard Stallman
  1 sibling, 1 reply; 10+ messages in thread
From: Chris Gray @ 2003-07-28 20:22 UTC (permalink / raw)


On Mon, 28 Jul 2003, Stefan Monnier wrote:
>> Chris Gray <christopher.gray@mail.mcgill.ca> writes:
>> > Yep.  It happens when I start gnus too.  I really don't know why,
>> > and these "async errors" seem very hard to debug.
>> 
>> Hmmm, actually, come to think of it, there's a function to make
>> emacs use X `synchronously', which might make debugging easier...
>> 
>>    x-synchronize is a built-in function.
>>    (x-synchronize ON &optional DISPLAY)
>> 
>>    If ON is non-nil, report errors as soon as the erring request is
>>    made.  If ON is nil, allow buffering of requests.  This is a
>>    noop on Mac OS systems.  The optional second argument DISPLAY
>>    specifies which display to act on.  DISPLAY should be either a
>>    frame or a display name (a string).  If DISPLAY is omitted or
>>    nil, that stands for the selected frame's display.
>> 
>> -Miles
> 
> I don't think it's going to help.  The `async error' is generally
> due to missing BLOCK_INPUT statements that lead to Xlib functions
> being called from the signal handler while we're already inside
> an Xlib function.

This is exactly what the problem was.  In my patch you will notice
that I had BLOCK_INPUT and UNBLOCK_INPUT commented for some strange
reason.  Uncommenting it made the async errors go away.

I want to fix some other things before sending another patch, but
those who are already testing my first patch should know what to do. 

Cheers,
Chris

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-28 20:04       ` Stefan Monnier
  2003-07-28 20:22         ` Chris Gray
@ 2003-07-30 20:31         ` Richard Stallman
  2003-07-31 14:35           ` Stefan Monnier
  1 sibling, 1 reply; 10+ messages in thread
From: Richard Stallman @ 2003-07-30 20:31 UTC (permalink / raw)
  Cc: emacs-devel, miles

    My patch that makes the signal handler trivial (and handles "async"
    signals from the QUIT macro instead) should solve this problem once and
    for all.

Can you install it in such a way that it is not hard to remove?

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-30 20:31         ` Richard Stallman
@ 2003-07-31 14:35           ` Stefan Monnier
  0 siblings, 0 replies; 10+ messages in thread
From: Stefan Monnier @ 2003-07-31 14:35 UTC (permalink / raw)
  Cc: emacs-devel, Stefan Monnier, miles

>     My patch that makes the signal handler trivial (and handles "async"
>     signals from the QUIT macro instead) should solve this problem once and
>     for all.
> 
> Can you install it in such a way that it is not hard to remove?

I'll see about cleaning it up and conditionalizing with #ifdefs
(shouldn't be too hard).


	Stefan


PS: I'm leaving today for a week in chocolate country and I'll be
    moving to Montreal right after that, so don't expect it right away.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: antialiasing for emacs
  2003-07-28 20:22         ` Chris Gray
@ 2003-08-13 10:48           ` Miles Bader
  0 siblings, 0 replies; 10+ messages in thread
From: Miles Bader @ 2003-08-13 10:48 UTC (permalink / raw)


Hi,

I have question about your emacs xft support patch:

Your code contains the following:

+    face->xftbackground.pixel = face->background;
+    newcolor.pixel = face->background;
+    XQueryColor (FRAME_X_DISPLAY (f), atts.colormap, &newcolor);
+    face->xftbackground.color.red = newcolor.red;
+    face->xftbackground.color.green = newcolor.green;
+    face->xftbackground.color.blue = newcolor.blue;
+    face->xftbackground.color.alpha = 0xffff;

Is there any way to use a pixmap instead of a single color?

I've been working on my pixmap background patch for emacs, and I'm a
bit concerned that it won't interact correctly with font anti-aliasing
(GTK presents similar problems, but they can be worked around in a
brute-force manner).

I'm hoping that it's possible, because Mozilla uses xft, and it
certainly supports anti-aliased fonts on top of pixmap backgrounds.

Thanks,

-Miles
-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-08-13 10:48 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-24 20:37 antialiasing for emacs Chris Gray
2003-07-25  2:02 ` Miles Bader
2003-07-25 19:07   ` Chris Gray
2003-07-27 22:33     ` Miles Bader
2003-07-28 20:04       ` Stefan Monnier
2003-07-28 20:22         ` Chris Gray
2003-08-13 10:48           ` Miles Bader
2003-07-30 20:31         ` Richard Stallman
2003-07-31 14:35           ` Stefan Monnier
2003-07-27  4:28 ` Marcelo Toledo

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.