unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Antialiased text on X11
@ 2005-03-10 21:45 James Cloos
  2005-03-10 22:25 ` Stefan Monnier
  0 siblings, 1 reply; 44+ messages in thread
From: James Cloos @ 2005-03-10 21:45 UTC (permalink / raw)


There have been various pleas and debates on this posted on and off
over at least the past several months.

There are several options for doing this, but I beleive Cairo (cf
http://cairographics.org) is the best choice.

This would not be on top of the current X11 support, but parallel to
it (and to the mac and win gui support).  This leaves the X11 code
as is to support platforms w/o cairo and by keeping legacy stuff out
helps to ensure the new port is clean.

The Cairo team recently released version 0.4 but is about to change
the API considerably.  It looks unlikely that there will be any
significant API changes after this shakeup.  Any work on a cairo gui
for emacs should wait at least a fortnight or two to ensure a stable
API.  Which fits in well with getting 22.1 relased first.  :-)

This should provide a clean platform for antialiased text, overlays of
combining diacritics and other typographic features within the text
buffers and should work well for emacs applications like preview-latex,
xml modes with a similar intent or any graphics-heavy app.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

PS.  I can spend devel time on this, though will wait until
     cairo's api is settled.

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

* Re: Antialiased text on X11
  2005-03-10 21:45 Antialiased text on X11 James Cloos
@ 2005-03-10 22:25 ` Stefan Monnier
  2005-03-10 23:15   ` Han Boetes
  2005-03-10 23:19   ` James Cloos
  0 siblings, 2 replies; 44+ messages in thread
From: Stefan Monnier @ 2005-03-10 22:25 UTC (permalink / raw)
  Cc: emacs-devel

> This would not be on top of the current X11 support, but parallel to
> it (and to the mac and win gui support).  This leaves the X11 code
> as is to support platforms w/o cairo and by keeping legacy stuff out
> helps to ensure the new port is clean.

A Cairo port will probably make sense at some point, but I think that
anti-aliasing support for X11 (using xft) is more urgent.


        Stefan

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

* Re: Antialiased text on X11
  2005-03-10 22:25 ` Stefan Monnier
@ 2005-03-10 23:15   ` Han Boetes
  2005-03-11  4:58     ` Jan D.
  2005-03-18 21:21     ` Ali Ijaz Sheikh
  2005-03-10 23:19   ` James Cloos
  1 sibling, 2 replies; 44+ messages in thread
From: Han Boetes @ 2005-03-10 23:15 UTC (permalink / raw)


Stefan Monnier wrote:
> A Cairo port will probably make sense at some point, but I think that
> anti-aliasing support for X11 (using xft) is more urgent.

A lot of people _think_ they need AA support. Until I tell them about
the terminus-font that is. :-)

I tested the AA branch but that developer dislikes gtk so much he nearly
ripped it out. And that's the only toolkit that supports AA!



# Han

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

* Re: Antialiased text on X11
  2005-03-10 22:25 ` Stefan Monnier
  2005-03-10 23:15   ` Han Boetes
@ 2005-03-10 23:19   ` James Cloos
  2005-03-11  9:20     ` Geoffrey J. Teale
  1 sibling, 1 reply; 44+ messages in thread
From: James Cloos @ 2005-03-10 23:19 UTC (permalink / raw)
  Cc: emacs-devel

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

Stefan> A Cairo port will probably make sense at some point, but I
Stefan> think that anti-aliasing support for X11 (using xft) is more
Stefan> urgent.

I suspect that the amount of work to get fontconfig/xft support on top
of the current x11 gui is comparable to a cairo gui (using the x11 gui
as a design reference). 

Of course I could be wrong on that count....

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

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

* Re: Antialiased text on X11
  2005-03-10 23:15   ` Han Boetes
@ 2005-03-11  4:58     ` Jan D.
  2005-03-18 21:21     ` Ali Ijaz Sheikh
  1 sibling, 0 replies; 44+ messages in thread
From: Jan D. @ 2005-03-11  4:58 UTC (permalink / raw)
  Cc: emacs-devel

> Stefan Monnier wrote:
>> A Cairo port will probably make sense at some point, but I think that
>> anti-aliasing support for X11 (using xft) is more urgent.
>
> A lot of people _think_ they need AA support. Until I tell them about
> the terminus-font that is. :-)
>
> I tested the AA branch but that developer dislikes gtk so much he 
> nearly
> ripped it out. And that's the only toolkit that supports AA!

Where is that branch?  How do you access it?

	Jan D.

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

* Re: Antialiased text on X11
  2005-03-10 23:19   ` James Cloos
@ 2005-03-11  9:20     ` Geoffrey J. Teale
  2005-03-11 15:13       ` Jan D.
  0 siblings, 1 reply; 44+ messages in thread
From: Geoffrey J. Teale @ 2005-03-11  9:20 UTC (permalink / raw)



I'll stick my hand in the air here and say that I would favour people
putting effort into Cairo support rather than Xft.  

Isn't Cairo being used in Gtk now?  Could we get Cairo for free by
porting the buffer to Gtk? 

-- 
Geoff Teale
CMed Technology - gteale@cmedltd.com

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

* Re: Antialiased text on X11
  2005-03-11  9:20     ` Geoffrey J. Teale
@ 2005-03-11 15:13       ` Jan D.
  0 siblings, 0 replies; 44+ messages in thread
From: Jan D. @ 2005-03-11 15:13 UTC (permalink / raw)
  Cc: emacs-devel

>
> I'll stick my hand in the air here and say that I would favour people
> putting effort into Cairo support rather than Xft.
>
> Isn't Cairo being used in Gtk now?  Could we get Cairo for free by
> porting the buffer to Gtk?

GTK 2.6 does not use Cairo, the development version might.  As for 
"porting the buffer", I assume you mean that we should leave all 
redisplay to Gtk, by using for example the text widget?  Unfortunately 
the redisplay in that widget is crude and simple, and is only suitable 
for the most simple text editing tasks.

Getting Emacs to use Xft for all X ports is much more realistic.  Cairo 
is a moving target, and from what I have seen, we still need font 
metrics and the like to be able to handle redisplay.  Cairo only gives 
simple drawing primitives, this is not good enough.  I haven't seen the 
latest Cairo sources, so this might have changed.

But if we get font metrics from Cairo or Xft does not matter much, the 
porting work is roughly the same, so Xft is a much better target.  The 
drawing stuff is trivial in both cases.

	Jan D.

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

* Re: Antialiased text on X11
  2005-03-10 23:15   ` Han Boetes
  2005-03-11  4:58     ` Jan D.
@ 2005-03-18 21:21     ` Ali Ijaz Sheikh
  2005-03-18 22:39       ` Drew Adams
  2005-03-19  0:59       ` Antialiased text on X11 Miles Bader
  1 sibling, 2 replies; 44+ messages in thread
From: Ali Ijaz Sheikh @ 2005-03-18 21:21 UTC (permalink / raw)


Han Boetes wrote:
> Stefan Monnier wrote:
> 
>>A Cairo port will probably make sense at some point, but I think that
>>anti-aliasing support for X11 (using xft) is more urgent.
> 
> 
> A lot of people _think_ they need AA support. Until I tell them about
> the terminus-font that is. :-)


I think that is a generalization; and a matter of opinion.

I have tried the terminus font; and atleast
a hundred other fonts.  The fact of the matter is that anti-aliased 
fonts specially on LCD screens look much better than non-antialiased 
fonts.  Its rather sad that I have to use xemacs on windows (such a 
heresy) in order to have my fonts antialised.

Ali

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

* RE: Antialiased text on X11
  2005-03-18 21:21     ` Ali Ijaz Sheikh
@ 2005-03-18 22:39       ` Drew Adams
  2005-03-19 22:45         ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos
  2005-03-19  0:59       ` Antialiased text on X11 Miles Bader
  1 sibling, 1 reply; 44+ messages in thread
From: Drew Adams @ 2005-03-18 22:39 UTC (permalink / raw)


    The fact of the matter is that anti-aliased
    fonts specially on LCD screens look much better than non-antialiased
    fonts.  Its rather sad that I have to use xemacs on windows (such a
    heresy) in order to have my fonts antialised.

I'm not an expert on anti-aliasing, but I use Windows XP on an LCD with
ClearType smoothing of screen font edges, and it works beautifully. I only
wish I had the same effect when I use Emacs on Linux (I'm not saying there
is no way to do that, but I'm ignorant of it).

If you use Windows XP, try this:

1. Right-click the desktop, choose Properties.
2. Open the Appearance tab (panel).
3. Click the Effects... button.
4. Check the box labeled "Use the following method to smooth edges of screen
fonts"
5. Choose ClearType or Standard (I use ClearType).
6. Click OK. Click OK.

Does that not do what you want?

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

* Re: Antialiased text on X11
  2005-03-18 21:21     ` Ali Ijaz Sheikh
  2005-03-18 22:39       ` Drew Adams
@ 2005-03-19  0:59       ` Miles Bader
  2005-03-19  6:27         ` Jan D.
  1 sibling, 1 reply; 44+ messages in thread
From: Miles Bader @ 2005-03-19  0:59 UTC (permalink / raw)
  Cc: emacs-devel

On Fri, 18 Mar 2005 16:21:06 -0500, Ali Ijaz Sheikh <ali@binish.com> wrote:
> > A lot of people _think_ they need AA support. Until I tell them about
> > the terminus-font that is. :-)
> 
> I think that is a generalization; and a matter of opinion.

Well, surely not, since he was relating his experience, not stating a
general rule... :-)  But I understand your point.

> The fact of the matter is that anti-aliased
> fonts specially on LCD screens look much better than non-antialiased
> fonts.

This however, _is_ a generalization, and a matter of opinion.

I use beautiful anti-aliased fonts (with sub-pixel rendering on an
LCD) every day in firefox and gnome apps (ft2's auto-hinting is
incredibly good), and I also use Emacs alongside them.  Emacs is not
noticeably less beautiful.

The reason is simply that -- like Hans -- I've found a font that I
really like which looks good without anti-aliasing.

I think that in general what Hans says is correct:  it depends very
much on the particular font whether anti-aliasing helps significantly
or not (there are certain fonts which I far _prefer_ "non-smoothed",
and wish I knew how to make ft stop smoothing just those fonts).

However Emacs not supporting anti-aliasing certainly restricts one's
choices of fonts, because many fonts out there don't look good without
AA, and one's choice of sizes, because at extremely small sizes AA
becomes much more necessary.  If a user particularly likes a font that
needs AA, he's surely going to be a bit annoyed that he can't use it
in Emacs.  Obviously you are.  :-)

So I think Emacs should definitely support AA when it can, but it's
surely not as fundamental a requirement as has been suggested...

[The question of whether to support just xft or try to go for an
entire new rendering layer like Cairo is interesting -- my impression
is that porting to a new rendering layer is actually fairly
straight-forward; it might be the easier task than figuring out the
convoluted Emacs font-selection machinery (required in either case I
guess -- but it means that "xft only" might not be any easier
really)!]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-19  0:59       ` Antialiased text on X11 Miles Bader
@ 2005-03-19  6:27         ` Jan D.
  2005-03-19  7:39           ` Miles Bader
                             ` (2 more replies)
  0 siblings, 3 replies; 44+ messages in thread
From: Jan D. @ 2005-03-19  6:27 UTC (permalink / raw)
  Cc: Ali Ijaz Sheikh, emacs-devel

> [The question of whether to support just xft or try to go for an
> entire new rendering layer like Cairo is interesting -- my impression
> is that porting to a new rendering layer is actually fairly
> straight-forward; it might be the easier task than figuring out the
> convoluted Emacs font-selection machinery (required in either case I
> guess -- but it means that "xft only" might not be any easier
> really)!]

I have started on Xft support, but it is really something for the 
release after the next, so I don't spend much time on it yet.  I can 
confirm your reasoning, the Emacs font-selection machinery is indeed 
the most tricky part, I have not done that fully, so I can't change 
font yet.  But part of the problem is that the Xft font selection is 
entirely new compared to the old X font selection.

The rendering was not that difficult, it was more finding the right 
font metrics that required some thought.  Finally, the rendering (i.e. 
the actual drawing of text) is trivial in comparison.  To use Cairo 
would not have helped a bit, rather the opposite.  I'd would requre we 
dump most of the redisplay engine and let Cairo take care of it for 
Cairo to give any extra value.

I am doing an Xft solution, I did not find the talked about Xft branch, 
so I started from scratch.  The main reason for doing this is that I 
wanted to use the GTK file selection dialog, but since that dialog 
displays all fonts, including antialiased, Emacs can currently not use 
it.

	Jan D.

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

* Re: Antialiased text on X11
  2005-03-19  6:27         ` Jan D.
@ 2005-03-19  7:39           ` Miles Bader
  2005-03-19 16:31           ` Stefan Monnier
  2005-03-22 12:45           ` Oliver Scholz
  2 siblings, 0 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-19  7:39 UTC (permalink / raw)
  Cc: emacs-devel, Ali Ijaz Sheikh, miles

On Sat, 19 Mar 2005 07:27:38 +0100, Jan D. <jan.h.d@swipnet.se> wrote:
> I am doing an Xft solution, I did not find the talked about Xft branch,
> so I started from scratch.

No biggie I think -- the "xft branch" was pretty crufty as I remember
it, more a proof of concept than anything else.  Since you're
well-acquainted with Emacs internals, you're probably a good person to
do the job right.

[The original archive containing that work was at
http://www.cs.ubc.ca/~cmg/{archive}, but it seems to be gone now.]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-19  6:27         ` Jan D.
  2005-03-19  7:39           ` Miles Bader
@ 2005-03-19 16:31           ` Stefan Monnier
  2005-03-19 16:53             ` Han Boetes
                               ` (3 more replies)
  2005-03-22 12:45           ` Oliver Scholz
  2 siblings, 4 replies; 44+ messages in thread
From: Stefan Monnier @ 2005-03-19 16:31 UTC (permalink / raw)
  Cc: snogglethorpe, emacs-devel, Ali Ijaz Sheikh, miles

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

> I have started on Xft support, but it is really something for the release
> after the next, so I don't spend much time on it yet.  I can confirm your
> reasoning, the Emacs font-selection machinery is indeed the most tricky
> part, I have not done that fully, so I can't change font yet.  But part of
> the problem is that the Xft font selection is entirely new compared to the
> old X font selection.

Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-)

> I am doing an Xft solution, I did not find the talked about Xft branch, so
> I started from scratch.  The main reason for doing this is that I wanted to
> use the GTK file selection dialog, but since that dialog displays all fonts,
> including antialiased, Emacs can currently not use it.

I don't think you wasted your time, but in case you're interested, I've
appended a patch I extracted from that xft branch at some point.  I had some
trouble extracting the patch, so there might be some missing bits and some
unrelated extra bits.  It surely doesn't compile.


        Stefan



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

Seulement dans xft-base/src: .arch-ids
Seulement dans xft-base/src: bitmaps
Seulement dans xft-base/src: ChangeLog
Seulement dans xft-base/src: ChangeLog.1
Seulement dans xft-base/src: ChangeLog.2
Seulement dans xft-base/src: ChangeLog.3
Seulement dans xft-base/src: ChangeLog.4
Seulement dans xft-base/src: ChangeLog.5
Seulement dans xft-base/src: ChangeLog.6
Seulement dans xft-base/src: ChangeLog.7
Seulement dans xft-base/src: ChangeLog.8
Seulement dans xft-base/src: ChangeLog.9
Seulement dans xft/src.xft: config.h
Seulement dans xft-base/src: config.in
Seulement dans xft-base/src: COPYING
Seulement dans xft-base/src: .cvsignore
Seulement dans xft-base/src: cxux-crt0.s
Seulement dans xft-base/src: .dbxinit
diff -u --recursive xft-base/src/dispextern.h xft/src.xft/dispextern.h
--- xft-base/src/dispextern.h	2005-03-10 18:22:52.123027247 -0500
+++ xft/src.xft/dispextern.h	2005-03-10 18:18:01.264178566 -0500
@@ -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. */
@@ -1092,6 +1097,7 @@
 
   /* Font in which this string is to be drawn.  */
   XFontStruct *font;
+  XftFont *xftfont;
 
   /* Font info for this string.  */
   struct font_info *font_info;
@@ -1368,6 +1374,16 @@
      an id as returned from load_pixmap.  */
   int stipple;
 
+#ifdef HAVE_XFT
+  XftFont *xftfont;
+  XftColor xftforeground;
+  XftColor xftbackground;
+  XftDraw *draw;
+#endif
+
+  /* Reverse the foreground and background to make the cursor */
+  int reverse_color;
+
 #else /* not HAVE_WINDOW_SYSTEM */
 
   /* Dummy.  */
diff -u --recursive xft-base/src/dispnew.c xft/src.xft/dispnew.c
Seulement dans xft/src.xft: epaths.h
Seulement dans xft-base/src: epaths.in
diff -u --recursive xft-base/src/fontset.c xft/src.xft/fontset.c
diff -u --recursive xft-base/src/frame.c xft/src.xft/frame.c
Seulement dans xft-base/src: .gdbinit
Seulement dans xft-base/src: .gdbinit-union
diff -u --recursive xft-base/src/keyboard.c xft/src.xft/keyboard.c
Seulement dans xft-base/src: m
Seulement dans xft/src.xft: Makefile.c
Seulement dans xft-base/src: Makefile.in
Seulement dans xft-base/src: makefile.nt
Seulement dans xft-base/src: makefile.w32-in
Seulement dans xft-base/src: README
Seulement dans xft-base/src: s
Seulement dans xft-base/src: stamp-h.in
Seulement dans xft-base/src: temacs.opt
diff -u --recursive xft-base/src/window.c xft/src.xft/window.c
diff -u --recursive xft-base/src/xdisp.c xft/src.xft/xdisp.c
--- xft-base/src/xdisp.c	2005-03-10 18:22:58.088270349 -0500
+++ xft/src.xft/xdisp.c	2005-03-10 18:18:05.170337510 -0500
@@ -17332,10 +17233,10 @@
      default font, but record the fact that we couldn't load it in
      the glyph string so that we can draw rectangles for the
      characters of the glyph string.  */
-  if (s->font == NULL)
+  if (0 && s->font == NULL)
     {
       s->font_not_found_p = 1;
-      s->font = FRAME_FONT (s->f);
+      s->xftfont = FRAME_FONT (s->f);
     }
 
   /* Adjust base line for subscript/superscript text.  */
@@ -17399,17 +17300,17 @@
       ++glyph;
     }
 
-  s->font = s->face->font;
+  s->xftfont = s->face->xftfont;
   s->font_info = FONT_INFO_FROM_ID (s->f, s->face->font_info_id);
 
   /* If the specified font could not be loaded, use the frame's font,
      but record the fact that we couldn't load it in
      S->font_not_found_p so that we can draw rectangles for the
      characters of the glyph string.  */
-  if (s->font == NULL || glyph_not_available_p)
+  if (0 && (s->font == NULL || glyph_not_available_p))
     {
       s->font_not_found_p = 1;
-      s->font = FRAME_FONT (s->f);
+      s->xftfont = FRAME_FONT (s->f);
     }
 
   /* Adjust base line for subscript/superscript text.  */
@@ -18433,7 +18320,7 @@
      double *res;
      struct it *it;
      Lisp_Object prop;
-     XFontStruct *font;
+     XftFont *font;
      int width_p;
 {
   double pixels;
@@ -18601,7 +18488,7 @@
   int ascent = 0;
   double tem;
   struct face *face = FACE_FROM_ID (it->f, it->face_id);
-  XFontStruct *font = face->font ? face->font : FRAME_FONT (it->f);
+  XftFont *font = face->xftfont ? face->xftfont : FRAME_FONT (it->f);
 
   PREPARE_FACE_FOR_DISPLAY (it->f, face);
 
@@ -18726,7 +18613,7 @@
   if (it->what == IT_CHARACTER)
     {
       XChar2b char2b;
-      XFontStruct *font;
+      XftFont *font;
       struct face *face = FACE_FROM_ID (it->f, it->face_id);
       XCharStruct *pcm;
       int font_not_found_p;
@@ -18770,7 +18657,7 @@
       /* Get font to use.  Encode IT->char_to_display.  */
       get_char_face_and_encoding (it->f, it->char_to_display, it->face_id,
 				  &char2b, it->multibyte_p, 0);
-      font = face->font;
+      font = face->xftfont;
 
       /* When no suitable font found, use the default font.  */
       font_not_found_p = font == NULL;
@@ -18921,8 +18808,8 @@
 	     from the charset width; this is what old redisplay code
 	     did.  */
 
-	  pcm = rif->per_char_metric (font, &char2b,
-				      FONT_TYPE_FOR_MULTIBYTE (font, it->c));
+		pcm = rif->per_char_metric (font, &char2b,
+					    FONT_TYPE_FOR_MULTIBYTE (font, it->c));
 
 	  if (font_not_found_p || !pcm)
 	    {
@@ -18982,7 +18869,7 @@
       /* Note: A composition is represented as one glyph in the
 	 glyph matrix.  There are no padding glyphs.  */
       XChar2b char2b;
-      XFontStruct *font;
+      XftFont *font;
       struct face *face = FACE_FROM_ID (it->f, it->face_id);
       XCharStruct *pcm;
       int font_not_found_p;
@@ -19006,7 +18893,7 @@
       face = FACE_FROM_ID (it->f, it->face_id);
       get_char_face_and_encoding (it->f, it->char_to_display, it->face_id,
 				  &char2b, it->multibyte_p, 0);
-      font = face->font;
+      font = face->xftfont;
 
       /* When no suitable font found, use the default font.  */
       font_not_found_p = font == NULL;
@@ -19095,7 +18982,7 @@
 	      face = FACE_FROM_ID (it->f, face_id);
 	      get_char_face_and_encoding (it->f, ch, face->id,
 					  &char2b, it->multibyte_p, 0);
-	      font = face->font;
+	      font = face->xftfont;
 	      if (font == NULL)
 		{
 		  font = FRAME_FONT (it->f);
diff -u --recursive xft-base/src/xfaces.c xft/src.xft/xfaces.c
--- xft-base/src/xfaces.c	2005-03-10 18:22:58.188274425 -0500
+++ xft/src.xft/xfaces.c	2005-03-10 18:18:04.915327133 -0500
@@ -1063,7 +1063,8 @@
       /* Free the font.  */
       BLOCK_INPUT;
 #ifdef HAVE_X_WINDOWS
-      XFreeFont (dpyinfo->display, font_info->font);
+      // FIXME -- cmg
+      //XFreeFont (dpyinfo->display, font_info->font);
 #endif
 #ifdef WINDOWSNT
       w32_unload_font (dpyinfo, font_info->font);
@@ -5146,7 +5147,7 @@
       if (face->font)
 	{
 #ifdef HAVE_X_WINDOWS
-	  xgcv.font = face->font->fid;
+	  //xgcv.font = face->font->fid;
 #endif
 #ifdef WINDOWSNT
 	  xgcv.font = face->font;
@@ -5154,7 +5155,7 @@
 #ifdef MAC_OS
 	  xgcv.font = face->font;
 #endif
-	  mask |= GCFont;
+	  //mask |= GCFont;
 	}
 
       BLOCK_INPUT;
@@ -5169,6 +5170,53 @@
       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 = "-adobe-helvetica-medium-r-narrow--*-*-*-*-*-0-iso8859-1";
+      /*
+      char *name;
+      XFontStruct *fs = face->font;
+      Atom value;
+      XGetFontProperty (fs, XA_FONT, &value);
+      name = (char *) XGetAtomName(FRAME_X_DISPLAY (f), value);
+      */
+
+      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 */
 }
 
@@ -6879,6 +6927,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;
diff -u --recursive xft-base/src/xfns.c xft/src.xft/xfns.c
--- xft-base/src/xfns.c	2005-03-10 18:22:58.232276218 -0500
+++ xft/src.xft/xfns.c	2005-03-10 18:18:05.279341946 -0500
@@ -3041,14 +3042,14 @@
      Note that many default values are used.  */
 
   /* Normal video */
-  gc_values.font = FRAME_FONT (f)->fid;
+  //gc_values.font = FRAME_FONT (f)->fid;
   gc_values.foreground = f->output_data.x->foreground_pixel;
   gc_values.background = f->output_data.x->background_pixel;
   gc_values.line_width = 0;	/* Means 1 using fast algorithm.  */
   f->output_data.x->normal_gc
     = XCreateGC (FRAME_X_DISPLAY (f),
 		 FRAME_X_WINDOW (f),
-		 GCLineWidth | GCFont | GCForeground | GCBackground,
+		 GCLineWidth | /* GCFont | */ GCForeground | GCBackground,
 		 &gc_values);
 
   /* Reverse video style.  */
@@ -3057,7 +3058,7 @@
   f->output_data.x->reverse_gc
     = XCreateGC (FRAME_X_DISPLAY (f),
 		 FRAME_X_WINDOW (f),
-		 GCFont | GCForeground | GCBackground | GCLineWidth,
+		 /*GCFont |*/ GCForeground | GCBackground | GCLineWidth,
 		 &gc_values);
 
   /* Cursor has cursor-color background, background-color foreground.  */
@@ -3070,7 +3071,7 @@
 			     cursor_bits, 16, 16);
   f->output_data.x->cursor_gc
     = XCreateGC (FRAME_X_DISPLAY (f), FRAME_X_WINDOW (f),
-		 (GCFont | GCForeground | GCBackground
+		 (/*GCFont | */GCForeground | GCBackground
 		  | GCFillStyle /* | GCStipple */ | GCLineWidth),
 		 &gc_values);
 
@@ -3483,7 +3484,7 @@
 		       "autoLower", "AutoRaiseLower", RES_TYPE_BOOLEAN);
   x_default_parameter (f, parms, Qcursor_type, Qbox,
 		       "cursorType", "CursorType", RES_TYPE_SYMBOL);
-  x_default_parameter (f, parms, Qscroll_bar_width, Qnil,
+  x_default_parameter (f, parms, Qscroll_bar_width, make_number(0),
 		       "scrollBarWidth", "ScrollBarWidth",
 		       RES_TYPE_NUMBER);
 
@@ -3492,6 +3493,7 @@
      FRAME_LINES (f).  */
   width = FRAME_COLS (f);
   height = FRAME_LINES (f);
+  height = 40;
 
   SET_FRAME_COLS (f, 0);
   FRAME_LINES (f) = 0;
@@ -4221,7 +4223,8 @@
   for (i = 0; i < dpyinfo->n_fonts; i++)
     if (dpyinfo->font_table[i].name)
       {
-	XFreeFont (dpyinfo->display, dpyinfo->font_table[i].font);
+	// FIXME: should free -- cmg
+	//XFreeFont (dpyinfo->display, dpyinfo->font_table[i].font);
       }
 
   x_destroy_all_bitmaps (dpyinfo);
diff -u --recursive xft-base/src/xmenu.c xft/src.xft/xmenu.c
diff -u --recursive xft-base/src/xterm.c xft/src.xft/xterm.c
--- xft-base/src/xterm.c	2005-03-10 18:22:58.385282453 -0500
+++ xft/src.xft/xterm.c	2005-03-10 18:18:05.390346462 -0500
@@ -184,6 +184,10 @@
 
 int x_use_underline_position_properties;
 
+/* Non-zero means use Xft for anti-aliased fonts */
+
+int x_use_xft;
+
 /* This is a chain of structures for all the X displays currently in
    use.  */
 
@@ -287,7 +291,7 @@
 
 extern Lisp_Object Vx_no_window_manager;
 
-extern Lisp_Object Qeql;
+extern Lisp_Object Qface, Qmouse_face, Qeql;
 
 extern int errno;
 
@@ -326,7 +330,7 @@
 void x_wm_set_window_state P_ ((struct frame *, int));
 void x_wm_set_icon_pixmap P_ ((struct frame *, int));
 void x_initialize P_ ((void));
-static void x_font_min_bounds P_ ((XFontStruct *, int *, int *));
+static void x_font_min_bounds P_ ((XftFont *, int *, int *));
 static int x_compute_min_glyph_bounds P_ ((struct frame *));
 static void x_update_end P_ ((struct frame *));
 static void XTframe_up_to_date P_ ((struct frame *));
@@ -788,13 +778,31 @@
 
 static XCharStruct *
 x_per_char_metric (font, char2b, font_type)
-     XFontStruct *font;
+     XftFont *font;
      XChar2b *char2b;
      int font_type;  /* unused on X */
 {
   /* The result metric information.  */
-  XCharStruct *pcm = NULL;
+  static XCharStruct pcm;
+  XGlyphInfo extents;
+  Display *dpy;
+  XftChar16 ch;
+  if (NILP(x_display_name_list)) return NULL;
+  dpy =  x_display_info_for_name(XCAR(XCAR(x_display_name_list)))->display;
+
+  ch = (char2b->byte1 << 8) | char2b->byte2;
+  BLOCK_INPUT;
+  XftTextExtents16 (dpy, font, (XftChar16 *) &ch, 1, &extents);
+  UNBLOCK_INPUT;
+  pcm.ascent = font->ascent;
+  pcm.descent = font->descent;
+  pcm.lbearing = 0;
+  pcm.rbearing = 0;
+  pcm.width = extents.xOff;
+  //XCloseDisplay(dpy);
+  return &pcm;
 
+#if 0
   xassert (font && char2b);
 
   if (font->per_char != NULL)
@@ -852,6 +860,7 @@
   return ((pcm == NULL
 	   || (pcm->width == 0 && (pcm->rbearing - pcm->lbearing) == 0))
 	  ? NULL : pcm);
+#endif
 }
 
 
@@ -866,7 +875,9 @@
      int *two_byte_p;
 {
   int charset = CHAR_CHARSET (c);
-  XFontStruct *font = font_info->font;
+  return 0;
+#if 0
+  XftFont *font = font_info->font;
 
   /* FONT_INFO may define a scheme by which to encode byte1 and byte2.
      This may be either a program in a special encoder language or a
@@ -913,9 +924,10 @@
     }
 
   if (two_byte_p)
-    *two_byte_p = ((XFontStruct *) (font_info->font))->max_byte1 > 0;
+    *two_byte_p = ((XftFont *) (font_info->font))->max_byte1 > 0;
 
   return FONT_TYPE_UNKNOWN;
+#endif
 }
 
 
@@ -955,7 +967,7 @@
 				 int, int, int, XRectangle *));
 
 #if GLYPH_DEBUG
-static void x_check_font P_ ((struct frame *, XFontStruct *));
+static void x_check_font P_ ((struct frame *, XftFont *));
 #endif
 
 
@@ -966,7 +978,10 @@
 x_set_cursor_gc (s)
      struct glyph_string *s;
 {
-  if (s->font == FRAME_FONT (s->f)
+  //s->face = FACE_FROM_ID(s->f, CURSOR_FACE_ID);
+  s->gc = s->f->output_data.x->cursor_gc;
+  return;
+  if (s->xftfont == FRAME_FONT (s->f)
       && s->face->background == FRAME_BACKGROUND_PIXEL (s->f)
       && s->face->foreground == FRAME_FOREGROUND_PIXEL (s->f)
       && !s->cmp)
@@ -997,9 +1012,9 @@
 	}
 
       IF_DEBUG (x_check_font (s->f, s->font));
-      xgcv.font = s->font->fid;
+      //xgcv.font = s->font->fid;
       xgcv.graphics_exposures = False;
-      mask = GCForeground | GCBackground | GCFont | GCGraphicsExposures;
+      mask = GCForeground | GCBackground | /*GCFont |*/ GCGraphicsExposures;
 
       if (FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc)
 	XChangeGC (s->display, FRAME_X_DISPLAY_INFO (s->f)->scratch_cursor_gc,
@@ -1090,6 +1105,7 @@
 
   if (s->hl == DRAW_NORMAL_TEXT)
     {
+      s->face->reverse_color = 0;
       s->gc = s->face->gc;
       s->stippled_p = s->face->stipple != 0;
     }
@@ -1100,6 +1116,7 @@
     }
   else if (s->hl == DRAW_CURSOR)
     {
+      s->face->reverse_color = 1;
       x_set_cursor_gc (s);
       s->stippled_p = 0;
     }
@@ -1202,7 +1219,7 @@
 	  XSetFillStyle (s->display, s->gc, FillSolid);
 	  s->background_filled_p = 1;
 	}
-      else if (FONT_HEIGHT (s->font) < s->height - 2 * box_line_width
+      else if (FONT_HEIGHT (s->xftfont) < s->height - 2 * box_line_width
 	       || s->font_not_found_p
 	       || s->extends_to_end_of_line_p
 	       || force_p)
@@ -1216,6 +1233,61 @@
 }
 
 
+#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;
+#ifdef DEBUG_XFT_HEIGHTS
+      bgcolor->pixel = 0xff00;
+      newcolor.pixel = 0xff00;
+#else
+      bgcolor->pixel = vals.background;
+      newcolor.pixel = vals.background;
+#endif
+      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.  */
 
 static void
@@ -1266,28 +1338,93 @@
       if (s->for_overlaps_p
 	  || (s->background_filled_p && s->hl != DRAW_CURSOR))
 	{
-	  /* 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);
+#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);
+	    }
+	  else 
+	    {
+#ifdef HAVE_XFT
+	      XftColor *foreground;
+	      
+	      //x_get_colors_from_gc (s, &foreground, NULL);
+	      foreground = &(s->face->xftforeground);
+	      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);
+	  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
-	    XDrawImageString (s->display, s->window, s->gc, x,
-			      s->ybase - boff, char1b, s->nchars);
+	    {
+#ifdef HAVE_XFT
+	      XftColor *foreground, *background;
+
+	      //x_get_colors_from_gc (s, &foreground, &background);
+	      if (!s->face->reverse_color) {
+		foreground = &(s->face->xftforeground);
+		background = &(s->face->xftbackground);
+	      } else {
+		foreground = &(s->face->xftbackground);
+		background = &(s->face->xftforeground);
+	      }
+	      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;
+		  int a, d;
+		  XGlyphInfo extents;
+		  XftTextExtents8 (s->display, s->face->xftfont, char1b, s->nchars, &extents);
+		  width = extents.xOff;
+		  height = s->face->xftfont->ascent + s->face->xftfont->descent;
+		  a = s->face->xftfont->ascent;
+		  d = s->face->xftfont->descent;
+
+		  XftDrawRect (s->face->draw, background, x, s->ybase - a, width, height);
+		  XftDrawString8 (s->face->draw, foreground, s->face->xftfont, x, s->ybase, char1b, s->nchars);
+		}
+#endif
+	    }
 	}
 
-      if (s->face->overstrike)
+      if (0 && s->face->overstrike)
 	{
 	  /* For overstriking (to simulate bold-face), draw the
 	     characters again shifted to the right by one pixel.  */
+	  printf("overstrike\n");
 	  if (s->two_byte_p)
 	    XDrawString16 (s->display, s->window, s->gc, x + 1,
 			   s->ybase - boff, s->char2b, s->nchars);
@@ -2615,8 +2752,9 @@
 	  unsigned long tem, h;
 	  int y;
 
+	  // FIXME -- cmg
 	  /* Get the underline thickness.  Default is 1 pixel.  */
-	  if (!XGetFontProperty (s->font, XA_UNDERLINE_THICKNESS, &h))
+	  //if (!XGetFontProperty (s->font, XA_UNDERLINE_THICKNESS, &h))
 	    h = 1;
 
 	  /* Get the underline position.  This is the recommended
@@ -2627,12 +2765,15 @@
 	     ROUND ((maximum descent) / 2), with
 	     ROUND(x) = floor (x + 0.5)  */
 
+	    /* FIXME -- cmg
+
 	  if (x_use_underline_position_properties
 	      && XGetFontProperty (s->font, XA_UNDERLINE_POSITION, &tem))
 	    y = s->ybase + (long) tem;
 	  else if (s->face->font)
 	    y = s->ybase + (s->face->font->max_bounds.descent + 1) / 2;
 	  else
+	    */
 	    y = s->y + s->height - h;
 
 	  if (s->face->underline_defaulted_p)
@@ -4772,7 +4913,7 @@
 			    left + VERTICAL_SCROLL_BAR_WIDTH_TRIM,
 			    top,
 			    width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2,
-			    height,
+			    1,
 			    /* Border width, depth, class, and visual.  */
 			     0,
 			    CopyFromParent,
@@ -4993,6 +5134,9 @@
   width = WINDOW_CONFIG_SCROLL_BAR_COLS (w) * FRAME_COLUMN_WIDTH (f);
   height = window_height;
 
+  // FIXME -- cmg
+  width = 2 * FRAME_COLUMN_WIDTH (f);
+
   /* Compute the left edge of the scroll bar area.  */
   left = WINDOW_SCROLL_BAR_AREA_X (w);
 
@@ -5026,8 +5170,11 @@
 			left, top, width, height, False);
 	  UNBLOCK_INPUT;
 	}
-
-      bar = x_scroll_bar_create (w, top, sb_left, sb_width, height);
+      // FIXME -- cmg
+      //bar = x_scroll_bar_create (w, top, sb_left, 10 /*sb_width*/, height);
+      BLOCK_INPUT;
+      bar = x_scroll_bar_create (w, top, sb_left, 10, height);
+      UNBLOCK_INPUT;
     }
   else
     {
@@ -5118,6 +5265,11 @@
 	  wc.y = top;
 	  wc.width = sb_width - VERTICAL_SCROLL_BAR_WIDTH_TRIM * 2;
 	  wc.height = height;
+
+	  wc.x = 10;
+	  wc.y = 1;
+	  wc.height = 10;
+	  wc.width = 10;
 	  XConfigureWindow (FRAME_X_DISPLAY (f), SCROLL_BAR_X_WINDOW (bar),
 			    mask, &wc);
 	}
@@ -7939,52 +8073,27 @@
      struct frame *f;
      register char *fontname;
 {
-  struct font_info *fontp
-    = FS_LOAD_FONT (f, 0, fontname, -1);
-
-  if (!fontp)
-    return Qnil;
-
-  FRAME_FONT (f) = (XFontStruct *) (fontp->font);
-  FRAME_BASELINE_OFFSET (f) = fontp->baseline_offset;
+  //FRAME_FONT(f) = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen (FRAME_X_DISPLAY (f)), fontname);
+  char *foo = "-adobe-helvetica-medium-r-narrow--*-*-*-*-*-0-iso8859-1";
+  FcPattern *pat;
+  XftFont *fon;
+
+  //pat = XftXlfdParse (foo, 1, 0);
+  //if(!pat) return Qnil;
+  fon = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen (FRAME_X_DISPLAY (f)), fontname);
+  //fon = XftFontOpenPattern (FRAME_X_DISPLAY (f), pat);
+  if(!fon) return Qnil;
+  FRAME_FONT(f) = fon;
+  //free(pat);
+  FRAME_BASELINE_OFFSET (f) = 0;
   FRAME_FONTSET (f) = -1;
 
-  FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f));
+  FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f)) + 2;
   FRAME_LINE_HEIGHT (f) = FONT_HEIGHT (FRAME_FONT (f));
-
-  compute_fringe_widths (f, 1);
-
-  /* Compute the scroll bar width in character columns.  */
-  if (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) > 0)
-    {
-      int wid = FRAME_COLUMN_WIDTH (f);
-      FRAME_CONFIG_SCROLL_BAR_COLS (f)
-	= (FRAME_CONFIG_SCROLL_BAR_WIDTH (f) + wid-1) / wid;
-    }
-  else
-    {
-      int wid = FRAME_COLUMN_WIDTH (f);
-      FRAME_CONFIG_SCROLL_BAR_COLS (f) = (14 + wid - 1) / wid;
-    }
-
-  /* Now make the frame display the given font.  */
-  if (FRAME_X_WINDOW (f) != 0)
-    {
-      XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->normal_gc,
-		FRAME_FONT (f)->fid);
-      XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->reverse_gc,
-		FRAME_FONT (f)->fid);
-      XSetFont (FRAME_X_DISPLAY (f), f->output_data.x->cursor_gc,
-		FRAME_FONT (f)->fid);
-
-      /* Don't change the size of a tip frame; there's no point in
-	 doing it because it's done in Fx_show_tip, and it leads to
-	 problems because the tip frame has no widget.  */
-      if (NILP (tip_frame) || XFRAME (tip_frame) != f)
-	x_set_window_size (f, 0, FRAME_COLS (f), FRAME_LINES (f));
-    }
-
-  return build_string (fontp->full_name);
+  FRAME_BASELINE_OFFSET (f) = 0;
+  if (FRAME_X_WINDOW (f) != 0) 
+    x_set_window_size (f, 0, FRAME_COLS (f), FRAME_LINES (f));
+  return FRAME_FONT (f) ? build_string (fontname) : Qnil;
 }
 
 /* Give frame F the fontset named FONTSETNAME as its default font, and
@@ -9496,288 +9604,14 @@
      int size;
      int maxnames;
 {
-  Lisp_Object list = Qnil, patterns, newlist = Qnil, key = Qnil;
-  Lisp_Object tem, second_best;
-  struct x_display_info *dpyinfo
-    = f ? FRAME_X_DISPLAY_INFO (f) : x_display_list;
-  Display *dpy = dpyinfo->display;
-  int try_XLoadQueryFont = 0;
-  int count;
-  int allow_auto_scaled_font = 0;
-
-  if (size < 0)
-    {
-      allow_auto_scaled_font = 1;
-      size = 0;
-    }
-
-  patterns = Fassoc (pattern, Valternate_fontname_alist);
-  if (NILP (patterns))
-    patterns = Fcons (pattern, Qnil);
-
-  if (maxnames == 1 && !size)
-    /* We can return any single font matching PATTERN.  */
-    try_XLoadQueryFont = 1;
-
-  for (; CONSP (patterns); patterns = XCDR (patterns))
-    {
-      int num_fonts;
-      char **names = NULL;
-
-      pattern = XCAR (patterns);
-      /* See if we cached the result for this particular query.
-         The cache is an alist of the form:
-	 ((((PATTERN . MAXNAMES) . SCALABLE) (FONTNAME . WIDTH) ...) ...)  */
-      tem = XCDR (dpyinfo->name_list_element);
-      key = Fcons (Fcons (pattern, make_number (maxnames)),
-		   allow_auto_scaled_font ? Qt : Qnil);
-      list = Fassoc (key, tem);
-      if (!NILP (list))
-	{
-	  list = Fcdr_safe (list);
-	  /* We have a cashed list.  Don't have to get the list again.  */
-	  goto label_cached;
-	}
-
-      /* At first, put PATTERN in the cache.  */
-
-      BLOCK_INPUT;
-      count = x_catch_errors (dpy);
-
-      if (try_XLoadQueryFont)
-	{
-	  XFontStruct *font;
-	  unsigned long value;
-
-	  font = XLoadQueryFont (dpy, SDATA (pattern));
-	  if (x_had_errors_p (dpy))
-	    {
-	      /* This error is perhaps due to insufficient memory on X
-                 server.  Let's just ignore it.  */
-	      font = NULL;
-	      x_clear_errors (dpy);
-	    }
-
-	  if (font
-	      && XGetFontProperty (font, XA_FONT, &value))
-	    {
-	      char *name = (char *) XGetAtomName (dpy, (Atom) value);
-	      int len = strlen (name);
-	      char *tmp;
-
-	      /* If DXPC (a Differential X Protocol Compressor)
-                 Ver.3.7 is running, XGetAtomName will return null
-                 string.  We must avoid such a name.  */
-	      if (len == 0)
-		try_XLoadQueryFont = 0;
-	      else
-		{
-		  num_fonts = 1;
-		  names = (char **) alloca (sizeof (char *));
-		  /* Some systems only allow alloca assigned to a
-                     simple var.  */
-		  tmp = (char *) alloca (len + 1);  names[0] = tmp;
-		  bcopy (name, names[0], len + 1);
-		  XFree (name);
-		}
-	    }
-	  else
-	    try_XLoadQueryFont = 0;
-
-	  if (font)
-	    XFreeFont (dpy, font);
-	}
-
-      if (!try_XLoadQueryFont)
-	{
-	  /* We try at least 10 fonts because XListFonts will return
-	     auto-scaled fonts at the head.  */
-          if (maxnames < 0)
-            {
-              int limit;
-
-              for (limit = 500;;)
-                {
-                  names = XListFonts (dpy, SDATA (pattern), limit, &num_fonts);
-                  if (num_fonts == limit)
-                    {
-                      BLOCK_INPUT;
-                      XFreeFontNames (names);
-                      UNBLOCK_INPUT;
-                      limit *= 2;
-                    }
-                  else
-                    break;
-                }
-            }
-          else
-            names = XListFonts (dpy, SDATA (pattern), max (maxnames, 10),
-                                &num_fonts);
-
-	  if (x_had_errors_p (dpy))
-	    {
-	      /* This error is perhaps due to insufficient memory on X
-                 server.  Let's just ignore it.  */
-	      names = NULL;
-	      x_clear_errors (dpy);
-	    }
-	}
-
-      x_uncatch_errors (dpy, count);
-      UNBLOCK_INPUT;
-
-      if (names)
-	{
-	  int i;
-
-	  /* Make a list of all the fonts we got back.
-	     Store that in the font cache for the display.  */
-	  for (i = 0; i < num_fonts; i++)
-	    {
-	      int width = 0;
-	      char *p = names[i];
-	      int average_width = -1, resx = 0, dashes = 0;
-
-	      /* Count the number of dashes in NAMES[I].  If there are
-		 14 dashes, the field value following 9th dash
-		 (RESOLUTION_X) is nonzero, and the field value
-		 following 12th dash (AVERAGE_WIDTH) is 0, this is a
-		 auto-scaled font which is usually too ugly to be used
-		 for editing.  Let's ignore it.  */
-	      while (*p)
-		if (*p++ == '-')
-		  {
-		    dashes++;
-		    if (dashes == 7) /* PIXEL_SIZE field */
-		      width = atoi (p);
-		    else if (dashes == 9)
-		      resx = atoi (p);
-		    else if (dashes == 12) /* AVERAGE_WIDTH field */
-		      average_width = atoi (p);
-		  }
-
-	      if (allow_auto_scaled_font
-		  || dashes < 14 || average_width != 0 || resx == 0)
-		{
-		  tem = build_string (names[i]);
-		  if (NILP (Fassoc (tem, list)))
-		    {
-		      if (STRINGP (Vx_pixel_size_width_font_regexp)
-			  && ((fast_c_string_match_ignore_case
-			       (Vx_pixel_size_width_font_regexp, names[i]))
-			      >= 0))
-			/* We can set the value of PIXEL_SIZE to the
-			  width of this font.  */
-			list = Fcons (Fcons (tem, make_number (width)), list);
-		      else
-			/* For the moment, width is not known.  */
-			list = Fcons (Fcons (tem, Qnil), list);
-		    }
-		}
-	    }
-
-	  if (!try_XLoadQueryFont)
-	    {
-	      BLOCK_INPUT;
-	      XFreeFontNames (names);
-	      UNBLOCK_INPUT;
-	    }
-	}
-
-      /* Now store the result in the cache.  */
-      XSETCDR (dpyinfo->name_list_element,
-	       Fcons (Fcons (key, list), XCDR (dpyinfo->name_list_element)));
-
-    label_cached:
-      if (NILP (list)) continue; /* Try the remaining alternatives.  */
-
-      newlist = second_best = Qnil;
-      /* Make a list of the fonts that have the right width.  */
-      for (; CONSP (list); list = XCDR (list))
-	{
-	  int found_size;
-
-	  tem = XCAR (list);
-
-	  if (!CONSP (tem) || NILP (XCAR (tem)))
-	    continue;
-	  if (!size)
-	    {
-	      newlist = Fcons (XCAR (tem), newlist);
-	      continue;
-	    }
-
-	  if (!INTEGERP (XCDR (tem)))
-	    {
-	      /* Since we have not yet known the size of this font, we
-		 must try slow function call XLoadQueryFont.  */
-	      XFontStruct *thisinfo;
-
-	      BLOCK_INPUT;
-	      count = x_catch_errors (dpy);
-	      thisinfo = XLoadQueryFont (dpy,
-					 SDATA (XCAR (tem)));
-	      if (x_had_errors_p (dpy))
-		{
-		  /* This error is perhaps due to insufficient memory on X
-		     server.  Let's just ignore it.  */
-		  thisinfo = NULL;
-		  x_clear_errors (dpy);
-		}
-	      x_uncatch_errors (dpy, count);
-	      UNBLOCK_INPUT;
-
-	      if (thisinfo)
-		{
-		  XSETCDR (tem,
-			   (thisinfo->min_bounds.width == 0
-			    ? make_number (0)
-			    : make_number (thisinfo->max_bounds.width)));
-		  BLOCK_INPUT;
-		  XFreeFont (dpy, thisinfo);
-		  UNBLOCK_INPUT;
-		}
-	      else
-		/* For unknown reason, the previous call of XListFont had
-		  returned a font which can't be opened.  Record the size
-		  as 0 not to try to open it again.  */
-		XSETCDR (tem, make_number (0));
-	    }
-
-	  found_size = XINT (XCDR (tem));
-	  if (found_size == size)
-	    newlist = Fcons (XCAR (tem), newlist);
-	  else if (found_size > 0)
-	    {
-	      if (NILP (second_best))
-		second_best = tem;
-	      else if (found_size < size)
-		{
-		  if (XINT (XCDR (second_best)) > size
-		      || XINT (XCDR (second_best)) < found_size)
-		    second_best = tem;
-		}
-	      else
-		{
-		  if (XINT (XCDR (second_best)) > size
-		      && XINT (XCDR (second_best)) > found_size)
-		    second_best = tem;
-		}
-	    }
-	}
-      if (!NILP (newlist))
-	break;
-      else if (!NILP (second_best))
-	{
-	  newlist = Fcons (XCAR (second_best), Qnil);
-	  break;
-	}
-    }
-
-  return newlist;
+  Lisp_Object list;
+  Lisp_Object str;
+  str = build_string("-adobe-helvetica-medium-r-normal--14-140-75-75-p-77-iso8859-1");
+  list = Fcons(str, Qnil);
+  list = Fcons(build_string("fixed"), list);
+  return list;
 }
 
-
 #if GLYPH_DEBUG
 
 /* Check that FONT is valid on frame F.  It is if it can be found in F's
@@ -9786,7 +9620,7 @@
 static void
 x_check_font (f, font)
      struct frame *f;
-     XFontStruct *font;
+     XftFont *font;
 {
   int i;
   struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
@@ -9804,24 +9638,27 @@
 #endif /* GLYPH_DEBUG != 0 */
 
 /* Set *W to the minimum width, *H to the minimum font height of FONT.
-   Note: There are (broken) X fonts out there with invalid XFontStruct
+   Note: There are (broken) X fonts out there with invalid XftFont
    min_bounds contents.  For example, handa@etl.go.jp reports that
    "-adobe-courier-medium-r-normal--*-180-*-*-m-*-iso8859-1" fonts
    have font->min_bounds.width == 0.  */
 
 static INLINE void
 x_font_min_bounds (font, w, h)
-     XFontStruct *font;
+     XftFont *font;
      int *w, *h;
 {
   *h = FONT_HEIGHT (font);
-  *w = font->min_bounds.width;
+  //*w = font->min_bounds.width;
+  *w = font->max_advance_width;
 
   /* Try to handle the case where FONT->min_bounds has invalid
      contents.  Since the only font known to have invalid min_bounds
      is fixed-width, use max_bounds if min_bounds seems to be invalid.  */
+#if 0
   if (*w <= 0)
     *w = font->max_bounds.width;
+#endif
 }
 
 
@@ -9837,7 +9674,7 @@
 {
   int i;
   struct x_display_info *dpyinfo = FRAME_X_DISPLAY_INFO (f);
-  XFontStruct *font;
+  XftFont *font;
   int old_width = dpyinfo->smallest_char_width;
   int old_height = dpyinfo->smallest_font_height;
 
@@ -9850,8 +9687,8 @@
 	struct font_info *fontp = dpyinfo->font_table + i;
 	int w, h;
 
-	font = (XFontStruct *) fontp->font;
-	xassert (font != (XFontStruct *) ~0);
+	font = (XftFont *) fontp->font;
+	xassert (font != (XftFont *) ~0);
 	x_font_min_bounds (font, &w, &h);
 
 	dpyinfo->smallest_font_height = min (dpyinfo->smallest_font_height, h);
@@ -9882,6 +9719,7 @@
   Lisp_Object font_names;
   int count;
 
+#if 0
   /* Get a list of all the fonts that match this name.  Once we
      have a list of matching fonts, we compare them against the fonts
      we already have by comparing names.  */
@@ -9901,11 +9739,11 @@
 			      SDATA (XCAR (tail)))))
 	    return (dpyinfo->font_table + i);
     }
-
+#endif
   /* Load the font and add it to the table.  */
   {
     char *full_name;
-    XFontStruct *font;
+    XftFont *font;
     struct font_info *fontp;
     unsigned long value;
     int i;
@@ -9920,7 +9758,8 @@
 
     BLOCK_INPUT;
     count = x_catch_errors (FRAME_X_DISPLAY (f));
-    font = (XFontStruct *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname);
+    //font = (XftFont *) XLoadQueryFont (FRAME_X_DISPLAY (f), fontname);
+    font = XftFontOpenXlfd (FRAME_X_DISPLAY (f), DefaultScreen(FRAME_X_DISPLAY(f)), fontname);
     if (x_had_errors_p (FRAME_X_DISPLAY (f)))
       {
 	/* This error is perhaps due to insufficient memory on X
@@ -9961,6 +9800,7 @@
     fontp->name = (char *) xmalloc (strlen (fontname) + 1);
     bcopy (fontname, fontp->name, strlen (fontname) + 1);
 
+#if 0
     /* Try to get the full name of FONT.  Put it in FULL_NAME.  */
     full_name = 0;
     if (XGetFontProperty (font, XA_FONT, &value))
@@ -9994,8 +9834,12 @@
       fontp->full_name = full_name;
     else
       fontp->full_name = fontp->name;
+#else
+    fontp->full_name = fontp->name;
+#endif
 
-    fontp->size = font->max_bounds.width;
+    //fontp->size = font->max_bounds.width;
+    fontp->size = font->max_advance_width;
     fontp->height = FONT_HEIGHT (font);
 
     if (NILP (font_names))
@@ -10035,6 +9879,7 @@
        uses this font.  So, we set information in fontp->encoding[1]
        which is never used by any charset.  If mapping can't be
        decided, set FONT_ENCODING_NOT_DECIDED.  */
+#if 0
     fontp->encoding[1]
       = (font->max_byte1 == 0
 	 /* 1-byte font */
@@ -10067,6 +9912,12 @@
     fontp->default_ascent
       = (XGetFontProperty (font, dpyinfo->Xatom_MULE_DEFAULT_ASCENT, &value)
 	 ? (long) value : 0);
+#else
+    fontp->encoding[1] = FONT_ENCODING_NOT_DECIDED;
+    fontp->baseline_offset = 0;
+    fontp->relative_compose = 0;
+    fontp->default_ascent = font->ascent;
+#endif
 
     /* Set global flag fonts_changed_p to non-zero if the font loaded
        has a character with a smaller width than any other character
@@ -10978,6 +10829,10 @@
 to 4.1, set this to nil.  */);
   x_use_underline_position_properties = 1;
 
+  DEFVAR_BOOL ("x-use-xft", &x_use_xft,
+	       doc: /* *Non-nil means to use Xft for anti-aliasing */);
+  x_use_xft = 1;
+
   DEFVAR_LISP ("x-toolkit-scroll-bars", &Vx_toolkit_scroll_bars,
     doc: /* What X toolkit scroll bars Emacs uses.
 A value of nil means Emacs doesn't use X toolkit scroll bars.
diff -u --recursive xft-base/src/xterm.h xft/src.xft/xterm.h
--- xft-base/src/xterm.h	2005-03-10 18:22:58.409283431 -0500
+++ xft/src.xft/xterm.h	2005-03-10 18:18:05.413347398 -0500
@@ -26,6 +26,8 @@
 #include <X11/Xatom.h>
 #include <X11/Xresource.h>
 
+#include <X11/Xft/Xft.h>
+
 #ifdef USE_X_TOOLKIT
 #include <X11/StringDefs.h>
 #include <X11/IntrinsicP.h>	/* CoreP.h needs this */
@@ -99,7 +101,8 @@
 #define WHITE_PIX_DEFAULT(f) WhitePixel (FRAME_X_DISPLAY (f), \
 					 XScreenNumberOfScreen (FRAME_X_SCREEN (f)))
 
-#define FONT_WIDTH(f)	((f)->max_bounds.width)
+// FIXME -- cmg
+#define FONT_WIDTH(f)	((f)->max_advance_width) 
 #define FONT_HEIGHT(f)	((f)->ascent + (f)->descent)
 #define FONT_BASE(f)    ((f)->ascent)
 #define FONT_DESCENT(f) ((f)->descent)
@@ -503,7 +506,7 @@
   int icon_bitmap;
 
   /* Default ASCII font of this frame.  */
-  XFontStruct *font;
+  XftFont *font;
 
   /* The baseline offset of the default ASCII font.  */
   int baseline_offset;
@@ -730,6 +733,7 @@
 
 /* Value is the smallest width of any character in any font on frame F.  */
 
+#if 0
 #define FRAME_SMALLEST_CHAR_WIDTH(F) \
      FRAME_X_DISPLAY_INFO(F)->smallest_char_width
 
@@ -737,6 +741,10 @@
 
 #define FRAME_SMALLEST_FONT_HEIGHT(F) \
      FRAME_X_DISPLAY_INFO(F)->smallest_font_height
+#else
+#define FRAME_SMALLEST_CHAR_WIDTH(F) 4
+#define FRAME_SMALLEST_FONT_HEIGHT(f) 3
+#endif
 
 /* Return a pointer to the image cache of frame F.  */
 

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

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

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

* Re: Antialiased text on X11
  2005-03-19 16:31           ` Stefan Monnier
@ 2005-03-19 16:53             ` Han Boetes
  2005-03-20 11:51               ` Jan D.
  2005-03-19 21:41             ` Miles Bader
                               ` (2 subsequent siblings)
  3 siblings, 1 reply; 44+ messages in thread
From: Han Boetes @ 2005-03-19 16:53 UTC (permalink / raw)


> -  if (s-> font == NULL)
> +  if (0 && s-> font == NULL)

I suppose this is a mistake.



# Han

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

* Re: Antialiased text on X11
  2005-03-19 16:31           ` Stefan Monnier
  2005-03-19 16:53             ` Han Boetes
@ 2005-03-19 21:41             ` Miles Bader
  2005-03-20 13:15             ` Jan D.
  2005-03-20 22:51             ` Jan D.
  3 siblings, 0 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-19 21:41 UTC (permalink / raw)
  Cc: Jan D., emacs-devel, Ali Ijaz Sheikh, miles

On Sat, 19 Mar 2005 11:31:35 -0500, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> > I have started on Xft support, but it is really something for the release
> > after the next, so I don't spend much time on it yet.  I can confirm your
> > reasoning, the Emacs font-selection machinery is indeed the most tricky
> > part, I have not done that fully, so I can't change font yet.  But part of
> > the problem is that the Xft font selection is entirely new compared to the
> > old X font selection.
> 
> Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-)

That would be nice... I'm particularly interested to about see whether
it conflicts with my background-image hacks (though I was similarly
nervous about your GTK port, and there ended up being very little
problem in that instance).

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* The WHY of Xft [was: Re: Antialiased text on X11]
  2005-03-18 22:39       ` Drew Adams
@ 2005-03-19 22:45         ` James Cloos
  2005-03-19 23:47           ` Miles Bader
  0 siblings, 1 reply; 44+ messages in thread
From: James Cloos @ 2005-03-19 22:45 UTC (permalink / raw)


It should be pointed out that antialiasing and sub-pixel rendering are
just two of the benefits of the client-side font system brought by Xft
and friends.

The other benefits are just as important.  Control and installation of
fonts are easier for most users, fonts with large encodings -- such as
CJKV fonts or any iso10646-encoded font -- use *much* less vm and data
transfer between client and server is reduced for most workloads.

Even w/o antialiasing the user's experience improves.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com> <http://jhcloos.com>

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

* Re: The WHY of Xft [was: Re: Antialiased text on X11]
  2005-03-19 22:45         ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos
@ 2005-03-19 23:47           ` Miles Bader
  2005-03-20 16:49             ` The WHY of Xft James Cloos
  0 siblings, 1 reply; 44+ messages in thread
From: Miles Bader @ 2005-03-19 23:47 UTC (permalink / raw)
  Cc: emacs-devel

On Sat, 19 Mar 2005 17:45:42 -0500, James Cloos <cloos@jhcloos.com> wrote:
> It should be pointed out that antialiasing and sub-pixel rendering are
> just two of the benefits of the client-side font system brought by Xft
> and friends.
> 
> The other benefits are just as important.  Control and installation of
> fonts are easier for most users

Can you explain in more detail?  I use debian, and Emacs already seems
able to use the same fonts as xft-using programs, albeit not in
anti-aliased form.

> fonts with large encodings -- such as
> CJKV fonts or any iso10646-encoded font -- use *much* less vm and data
> transfer between client and server is reduced for most workloads.

Doesn't the X server already support partial loading of large fonts?
[I mean the "-deferglyphs 16" in the X startup options.]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-19 16:53             ` Han Boetes
@ 2005-03-20 11:51               ` Jan D.
  0 siblings, 0 replies; 44+ messages in thread
From: Jan D. @ 2005-03-20 11:51 UTC (permalink / raw)
  Cc: emacs-devel

Han Boetes wrote:

>>-  if (s-> font == NULL)
>>+  if (0 && s-> font == NULL)
>>    
>>
>
>I suppose this is a mistake.
>

As the font is hardcoded it should always be found.  It may be that in 
the case of Xft s->font is NULL always.  I agree it looks strange, but I 
also use this device sometimes to "comment out" if/while/for statements.

    Jan D.

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

* Re: Antialiased text on X11
  2005-03-19 16:31           ` Stefan Monnier
  2005-03-19 16:53             ` Han Boetes
  2005-03-19 21:41             ` Miles Bader
@ 2005-03-20 13:15             ` Jan D.
  2005-03-20 22:51             ` Jan D.
  3 siblings, 0 replies; 44+ messages in thread
From: Jan D. @ 2005-03-20 13:15 UTC (permalink / raw)
  Cc: emacs-devel

Stefan Monnier wrote:

> I don't think you wasted your time, but in case you're interested, I've
>
>appended a patch I extracted from that xft branch at some point.  I had some
>trouble extracting the patch, so there might be some missing bits and some
>unrelated extra bits.  It surely doesn't compile.
>
>  
>

Thank you.

    Jan D.

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

* Re: The WHY of Xft
  2005-03-19 23:47           ` Miles Bader
@ 2005-03-20 16:49             ` James Cloos
  2005-03-20 22:30               ` Miles Bader
  2005-03-21  0:32               ` Kenichi Handa
  0 siblings, 2 replies; 44+ messages in thread
From: James Cloos @ 2005-03-20 16:49 UTC (permalink / raw)
  Cc: emacs-devel, miles

>>>>> “Miles” == Miles Bader <snogglethorpe@gmail.com> writes:

>> The other benefits are just as important.  Control and installation
>> of fonts are easier for most users

Miles> Can you explain in more detail?  I use debian, and Emacs
Miles> already seems able to use the same fonts as xft-using programs,
Miles> albeit not in anti-aliased form.

That is becasue debian did the hard work for those fonts that it
includes as part of the distribution.  The hard part for users
comes when they want to install a font not part of the dist,
whether one they've purchased or otherwise acquired.

It is much easier to just drop a font into ~/.fonts than to mess
with fonts.dir and fonts.scale files, etc.  At least for those
who've not been doing so for a couple of decades....  ☺

fc-cache should be run when the contents of the searched directories
change, but cli-averse users will probably use a gui not unlike that
on doze or macs which can do that for them.  mkfontscale has helped
ease installation of server-side fonts, but it is still not as easy.

Obviously for emacs it is less of an issue than for something like
gimp, but I’m sure it will come up for some.  Especially if packages
like preview-latex can use the client-side fonts to preview the entire
document as it is being edited rather than just selected portions.

>> fonts with large encodings -- such as CJKV fonts or any
>> iso10646-encoded font -- use *much* less vm and data transfer
>> between client and server is reduced for most workloads.

Miles> Doesn’t the X server already support partial loading of large
Miles> fonts?  [I mean the “-deferglyphs 16” in the X startup
Miles> options.]

I’m not familiar with deferglyphs; I don't remember it from any of
the discussions I read or participated in on the fontconfig, xfree
or freedesktop lists.  And I cannot find it in X(7x) or Xorg(1x).

My understanding is that when a (server-side) font is opened by the
X server it must determine all of the glyphs’ metrics, which requires
rendering all of them.

There are also still at least a couple of things I forgot to mention.
Server-side unicode fonts are limited to the bmp, so one cannot edit
scripts that use non-bmp characters w/o switching to client-side
fonts.  Client-side fonts are also necessary to take full advantage
of opentype features.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

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

* Re: The WHY of Xft
  2005-03-20 16:49             ` The WHY of Xft James Cloos
@ 2005-03-20 22:30               ` Miles Bader
  2005-03-21 14:24                 ` David Hansen
  2005-03-21 16:12                 ` James Cloos
  2005-03-21  0:32               ` Kenichi Handa
  1 sibling, 2 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-20 22:30 UTC (permalink / raw)
  Cc: emacs-devel, miles

On Sun, 20 Mar 2005 11:49:50 -0500, James Cloos <cloos@jhcloos.com> wrote:
> My understanding is that when a (server-side) font is opened by the
> X server it must determine all of the glyphs' metrics, which requires
> rendering all of them.

I think this is not true -- it seems to be exactly this behavior which
-deferglyphs stops.  Without -deferglyphs, there was indeed a
noticeable freeze when using a CJK font for the first time; I've not
encountered this freeze since.  Debian has had -deferglyphs as the
default for quite a long time (e.g. if you use gdm, in
/etc/X11/gdm/gdm.conf); perhaps other distros do not.

Can xft still use bitmap fonts?  In the case of CJK, the commonly
available X bitmap fonts do seem to be generally more attractive at
typical text-editor size than what freetype produces for commonly[*]
available scaled fonts.

[*] By commonly available, I really mean "free and packaged in Debian"
...  Not the best definition I suppose, but maybe indicative of what a
typical lazy user like me sees...

I'm all for xft BTW; don't let my sniping give you the opposite
impression... :-)

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-19 16:31           ` Stefan Monnier
                               ` (2 preceding siblings ...)
  2005-03-20 13:15             ` Jan D.
@ 2005-03-20 22:51             ` Jan D.
  2005-03-22 23:44               ` Miles Bader
  3 siblings, 1 reply; 44+ messages in thread
From: Jan D. @ 2005-03-20 22:51 UTC (permalink / raw)
  Cc: miles, snogglethorpe, Ali Ijaz Sheikh, emacs-devel

Stefan Monnier wrote:

>>I have started on Xft support, but it is really something for the release
>>after the next, so I don't spend much time on it yet.  I can confirm your
>>reasoning, the Emacs font-selection machinery is indeed the most tricky
>>part, I have not done that fully, so I can't change font yet.  But part of
>>the problem is that the Xft font selection is entirely new compared to the
>>old X font selection.
>>    
>>
>
>Feel free to put it on an Arch branch somewhere, or a branch in the CVS ;-)
>  
>

Okay, I've made a branch in CVS, tag is XFT_JHD_BRANCH (jhd is my 
initials).   I hope I didn't breake anything in CVS :-).  The font 
selection is incomplete, so you have to specify a font on the command 
line, like so:

% emacs -fn monospace-12

(or any other font you prefer).  Since the font selection is incomplete, 
the font choosen when no font is given is helvetica (a proportional 
font).  I'm sure there are drawing errors (I've sen some myself) and 
other errors.  Feel free to drop a me a mail about bugs you see, but I 
don't expect to spend any time on this until the current release is out 
of the door.

    Jan D.

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

* Re: The WHY of Xft
  2005-03-20 16:49             ` The WHY of Xft James Cloos
  2005-03-20 22:30               ` Miles Bader
@ 2005-03-21  0:32               ` Kenichi Handa
  1 sibling, 0 replies; 44+ messages in thread
From: Kenichi Handa @ 2005-03-21  0:32 UTC (permalink / raw)
  Cc: miles, snogglethorpe, emacs-devel

In article <m3r7iamfdd.fsf@lugabout.cloos.reno.nv.us>, James Cloos <cloos@jhcloos.com> writes:
> There are also still at least a couple of things I forgot to mention.
> Server-side unicode fonts are limited to the bmp, so one cannot edit
> scripts that use non-bmp characters w/o switching to client-side
> fonts.  Client-side fonts are also necessary to take full advantage
> of opentype features.

And, from a viewpoint of multilingualization, the biggest
advantage of using local-side font (via Xft or by freetype
directly) is that we can access such OpenType tables as
GSUB/GPOS for Indic, and etc.

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

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

* Re: The WHY of Xft
  2005-03-20 22:30               ` Miles Bader
@ 2005-03-21 14:24                 ` David Hansen
  2005-03-21 16:12                 ` James Cloos
  1 sibling, 0 replies; 44+ messages in thread
From: David Hansen @ 2005-03-21 14:24 UTC (permalink / raw)


On Mon, 21 Mar 2005 07:30:55 +0900 Miles Bader wrote:

> Can xft still use bitmap fonts?  In the case of CJK, the commonly
> available X bitmap fonts do seem to be generally more attractive at
> typical text-editor size than what freetype produces for commonly[*]
> available scaled fonts.

Debian unstable (but AFAIK you have to manually edit this file on
Debian):

$ cat /etc/fonts/local.conf
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <include ignore_missing="yes">/var/lib/defoma/fontconfig.d/fonts.conf</include>
<!-- Uncomment below to enable bitmapped fonts -->
  <dir>/usr/X11R6/lib/X11/fonts</dir>
<!-- Uncomment below to enable subpixel rendering -->
[...]

David

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

* Re: The WHY of Xft
  2005-03-20 22:30               ` Miles Bader
  2005-03-21 14:24                 ` David Hansen
@ 2005-03-21 16:12                 ` James Cloos
  1 sibling, 0 replies; 44+ messages in thread
From: James Cloos @ 2005-03-21 16:12 UTC (permalink / raw)
  Cc: emacs-devel, miles

>>>>> "Miles" == Miles Bader <snogglethorpe@gmail.com> writes:

Miles> I think this is not true -- it seems to be exactly this
Miles> behavior which -deferglyphs stops.

I’ve now found deferglyphs in Xserver(1).  As I said, it is
new to me, but it does seem to address that one issue.

Miles> Can xft still use bitmap fonts?

Xft can use anything freetype can render, including at least bdf,
pcf and sfnt bitmaps.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

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

* Re: Antialiased text on X11
  2005-03-19  6:27         ` Jan D.
  2005-03-19  7:39           ` Miles Bader
  2005-03-19 16:31           ` Stefan Monnier
@ 2005-03-22 12:45           ` Oliver Scholz
  2005-03-22 14:21             ` Stefan
  2 siblings, 1 reply; 44+ messages in thread
From: Oliver Scholz @ 2005-03-22 12:45 UTC (permalink / raw)


"Jan D." <jan.h.d@swipnet.se> writes:
[...]
> I have started on Xft support,

Just one issue that might come up later. I would be grateful if you'd
also think about ways to customize AA per font and/or face along the
way; provided that this is feasible at all.

AA may look good, but it also makes the characters look blurry which
can be a source of headaches for some people who are sensitive to
this. OTOH, some free scalable m17n fonts lack hinting, so they are
basically unusable on a computer screen withouth AA. Being able to
enable AA partially per font or face would get us the best of both
worlds.

    Oliver
-- 
2 Germinal an 213 de la Révolution
Liberté, Egalité, Fraternité!

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

* Re: Antialiased text on X11
  2005-03-22 12:45           ` Oliver Scholz
@ 2005-03-22 14:21             ` Stefan
  2005-03-22 14:29               ` Oliver Scholz
  0 siblings, 1 reply; 44+ messages in thread
From: Stefan @ 2005-03-22 14:21 UTC (permalink / raw)
  Cc: emacs-devel

> Just one issue that might come up later. I would be grateful if you'd
> also think about ways to customize AA per font and/or face along the
> way; provided that this is feasible at all.

AFAIK this can be controlled globally (for all Xft apps) with the config
file (whose name escapes me just now, fonts.conf or somesuch).


        Stefan

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

* Re: Antialiased text on X11
  2005-03-22 14:21             ` Stefan
@ 2005-03-22 14:29               ` Oliver Scholz
  2005-03-22 15:17                 ` David Kastrup
  0 siblings, 1 reply; 44+ messages in thread
From: Oliver Scholz @ 2005-03-22 14:29 UTC (permalink / raw)
  Cc: emacs-devel

Stefan <monnier@iro.umontreal.ca> writes:

>> Just one issue that might come up later. I would be grateful if you'd
>> also think about ways to customize AA per font and/or face along the
>> way; provided that this is feasible at all.
>
> AFAIK this can be controlled globally (for all Xft apps) with the config
> file (whose name escapes me just now, fonts.conf or somesuch).

Ah, that could solve the issue with the aforementioned m17n fonts.
Still, if it is feasible, I'd prefer a face attribute like
:anti-aliased or somesuch. It allows for greater flexibility when
customizing the appearance of Emacs. Another issue is that the
headache argument applies only to large chunks of body text. It would
be nice to have e.g. the Info header faces anti-aliased, but not the
body text.

    Oliver
-- 
Oliver Scholz               2 Germinal an 213 de la Révolution
Ostendstr. 61               Liberté, Egalité, Fraternité!
60314 Frankfurt a. M.       

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

* Re: Antialiased text on X11
  2005-03-22 14:29               ` Oliver Scholz
@ 2005-03-22 15:17                 ` David Kastrup
  0 siblings, 0 replies; 44+ messages in thread
From: David Kastrup @ 2005-03-22 15:17 UTC (permalink / raw)
  Cc: Stefan, emacs-devel

Oliver Scholz <alkibiades@gmx.de> writes:

> Stefan <monnier@iro.umontreal.ca> writes:
>
>>> Just one issue that might come up later. I would be grateful if
>>> you'd also think about ways to customize AA per font and/or face
>>> along the way; provided that this is feasible at all.
>>
>> AFAIK this can be controlled globally (for all Xft apps) with the
>> config file (whose name escapes me just now, fonts.conf or
>> somesuch).
>
> Ah, that could solve the issue with the aforementioned m17n fonts.
> Still, if it is feasible, I'd prefer a face attribute like
> :anti-aliased or somesuch. It allows for greater flexibility when
> customizing the appearance of Emacs.

It is completely contraproductive to demand exceptions and details
before an implementation is even started.  And it is the wrong point
of time for the discussion, anyway, since it detracts from the
release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

* Re: Antialiased text on X11
  2005-03-20 22:51             ` Jan D.
@ 2005-03-22 23:44               ` Miles Bader
  2005-03-23  2:30                 ` Miles Bader
  2005-03-23 17:50                 ` Jan D.
  0 siblings, 2 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-22 23:44 UTC (permalink / raw)
  Cc: miles, Stefan Monnier, Ali Ijaz Sheikh, emacs-devel

On Sun, 20 Mar 2005 23:51:37 +0100, Jan D. <jan.h.d@swipnet.se> wrote:
> Okay, I've made a branch in CVS, tag is XFT_JHD_BRANCH (jhd is my
> initials).   I hope I didn't breake anything in CVS :-)

BTW, any time you make a branch tag, it's also good to make a
corresponding non-branch `base' tag which is the trunk version the
branch is relative too.  This info is deducible (though tiresome to
do) from the branch versions _until_ you decide to merge updates from
the trunk, at which point it's not... [whereas if you have base tag,
you update the base tag when you do the merge]

You can see this in many other Emacs branches, e.g., `emacs-unicode-2'
(the branch tag), and `emacs-unicode-2-base' (the corresponding
non-branch base tag).  [I don't have one for `lexbind', but that's
because I'm lazy and do merging via other means.]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-22 23:44               ` Miles Bader
@ 2005-03-23  2:30                 ` Miles Bader
  2005-03-23 17:50                 ` Jan D.
  1 sibling, 0 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-23  2:30 UTC (permalink / raw)
  Cc: Ali Ijaz Sheikh, miles

FWIW, I've added Jan's branch to my arch archive as "emacs--xft-jhd--0".

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-22 23:44               ` Miles Bader
  2005-03-23  2:30                 ` Miles Bader
@ 2005-03-23 17:50                 ` Jan D.
  2005-03-25 21:40                   ` Miles Bader
  1 sibling, 1 reply; 44+ messages in thread
From: Jan D. @ 2005-03-23 17:50 UTC (permalink / raw)
  Cc: Emacs-Devel Devel


> BTW, any time you make a branch tag, it's also good to make a
> corresponding non-branch `base' tag which is the trunk version the
> branch is relative too.  This info is deducible (though tiresome to
> do) from the branch versions _until_ you decide to merge updates from
> the trunk, at which point it's not... [whereas if you have base tag,
> you update the base tag when you do the merge]

Thanks for the tip.

	Jan D.

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

* Re: Antialiased text on X11
  2005-03-23 17:50                 ` Jan D.
@ 2005-03-25 21:40                   ` Miles Bader
  2005-03-26  8:13                     ` Jan D.
  0 siblings, 1 reply; 44+ messages in thread
From: Miles Bader @ 2005-03-25 21:40 UTC (permalink / raw)
  Cc: Emacs-Devel Devel, Miles Bader

On Wed, 23 Mar 2005 18:50:53 +0100, Jan D. <jan.h.d@swipnet.se> wrote:
> > BTW, any time you make a branch tag, it's also good to make a
> > corresponding non-branch `base' tag which is the trunk version the
> > branch is relative too.
> 
> Thanks for the tip.

I notice you've done this, but it seems a bit odd --

For files that you've modified it looks correct, e.g. "src/xdisp.c":

        XFT_JHD_BRANCH_base: 1.992
        XFT_JHD_BRANCH: 1.992.0.2

But for files that you _haven't _ changed, it seems wrong, e.g.,
"src/editfns.c":

        XFT_JHD_BRANCH_base: 1.389.0.4
        XFT_JHD_BRANCH: 1.389.0.2

The "..._base" tag is branch tag when it shouldn't be.

Thanks,

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-25 21:40                   ` Miles Bader
@ 2005-03-26  8:13                     ` Jan D.
  2005-03-29 10:52                       ` Geoffrey J. Teale
  0 siblings, 1 reply; 44+ messages in thread
From: Jan D. @ 2005-03-26  8:13 UTC (permalink / raw)
  Cc: Emacs-Devel Devel

> I notice you've done this, but it seems a bit odd --
>
> For files that you've modified it looks correct, e.g. "src/xdisp.c":
>
>         XFT_JHD_BRANCH_base: 1.992
>         XFT_JHD_BRANCH: 1.992.0.2
>
> But for files that you _haven't _ changed, it seems wrong, e.g.,
> "src/editfns.c":
>
>         XFT_JHD_BRANCH_base: 1.389.0.4
>         XFT_JHD_BRANCH: 1.389.0.2
>
> The "..._base" tag is branch tag when it shouldn't be.

Thanks for checking this.  I only confirmed that the tag was on the 
correct version, I didn't know about these CVS special versions.  I've 
fixed it now (and read some more about CVS branching in general :-).

	Jan D.

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

* Re: Antialiased text on X11
  2005-03-26  8:13                     ` Jan D.
@ 2005-03-29 10:52                       ` Geoffrey J. Teale
  2005-03-29 11:28                         ` Miles Bader
  2005-03-29 19:28                         ` Jan D.
  0 siblings, 2 replies; 44+ messages in thread
From: Geoffrey J. Teale @ 2005-03-29 10:52 UTC (permalink / raw)
  Cc: Emacs-Devel Devel, Miles Bader


Hi,

I've just checked out and built this branch a couple of times (once
with Gtk once with LUCID).  In both cases I noticed that there were a
lot of artifacts being left around, in fact it seams that buffers and
mini-buffer are only being redrawn when I resize the emacs window.  If
I don't resize the window everything quickly becomes unreadable.

I assume this is just a result of the current, early state of
development, but just in case I'm the only one experiencing this
problem I though I'd mention it

-- 
Geoff Teale
CMed Technology            -   gteale@cmedresearch.com

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

* Re: Antialiased text on X11
  2005-03-29 10:52                       ` Geoffrey J. Teale
@ 2005-03-29 11:28                         ` Miles Bader
  2005-03-29 12:24                           ` Geoffrey J. Teale
  2005-03-29 18:24                           ` Henrik Enberg
  2005-03-29 19:28                         ` Jan D.
  1 sibling, 2 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-29 11:28 UTC (permalink / raw)
  Cc: Jan D., Emacs-Devel Devel, Miles Bader

On Tue, 29 Mar 2005 11:52:07 +0100, Geoffrey J. Teale
<gteale@cmedltd.com> wrote:
> I assume this is just a result of the current, early state of
> development, but just in case I'm the only one experiencing this
> problem I though I'd mention it

I saw it too -- it doesn't seem to ever clear to background color
before drawing.

[There are some other odd effects like color fringing that make me
wonder if it's assuming a white background.]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-29 11:28                         ` Miles Bader
@ 2005-03-29 12:24                           ` Geoffrey J. Teale
  2005-03-29 18:24                           ` Henrik Enberg
  1 sibling, 0 replies; 44+ messages in thread
From: Geoffrey J. Teale @ 2005-03-29 12:24 UTC (permalink / raw)
  Cc: Jan D., Emacs-Devel Devel, miles

Miles Bader <snogglethorpe@gmail.com> writes:
> I saw it too -- it doesn't seem to ever clear to background color
> before drawing.
>
> [There are some other odd effects like color fringing that make me
> wonder if it's assuming a white background.]

I notice that, rather randomly, if I drag another window across some
text (folder names in GNUS) the characters get thicker when I go
anti-clockwise and thinner when I go clockwise.   That's some kind of weird.

-- 
Geoff Teale
CMed Technology            -   gteale@cmedresearch.com

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

* Re: Antialiased text on X11
  2005-03-29 11:28                         ` Miles Bader
  2005-03-29 12:24                           ` Geoffrey J. Teale
@ 2005-03-29 18:24                           ` Henrik Enberg
  2005-03-29 22:50                             ` Miles Bader
  1 sibling, 1 reply; 44+ messages in thread
From: Henrik Enberg @ 2005-03-29 18:24 UTC (permalink / raw)
  Cc: Emacs-Devel Devel, Jan D., Geoffrey J. Teale, miles

Miles Bader <snogglethorpe@gmail.com> writes:

[...]

> [There are some other odd effects like color fringing that make me
> wonder if it's assuming a white background.]

that might be your setup. fontconfig has options for how colors should
be blended, and in my experience it's basically impossible to get a good
setup for both dark text/light background and vice versa. 

-- 
Vaya Con Satan

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

* Re: Antialiased text on X11
  2005-03-29 10:52                       ` Geoffrey J. Teale
  2005-03-29 11:28                         ` Miles Bader
@ 2005-03-29 19:28                         ` Jan D.
  2005-04-01  8:15                           ` Miles Bader
  1 sibling, 1 reply; 44+ messages in thread
From: Jan D. @ 2005-03-29 19:28 UTC (permalink / raw)
  Cc: Miles Bader, Emacs-Devel Devel

Geoffrey J. Teale wrote:

>Hi,
>
>I've just checked out and built this branch a couple of times (once
>with Gtk once with LUCID).  In both cases I noticed that there were a
>lot of artifacts being left around, in fact it seams that buffers and
>mini-buffer are only being redrawn when I resize the emacs window.  If
>I don't resize the window everything quickly becomes unreadable.
>
>I assume this is just a result of the current, early state of
>development, but just in case I'm the only one experiencing this
>problem I though I'd mention it
>  
>

I don't see that (but other minor redrawing errors).  I suspect your 
version of fontconfig and/or Xrender is different from mine.  I'll test 
this further on older X versions when Emacs has been released.  You can 
try to modify xterm.c here:

#ifdef HAVE_XFT
      if (! (s->for_overlaps_p
             || (s->background_filled_p && s->hl != DRAW_CURSOR)))
        XftDrawRect (s->face->xft_draw,
                     s->hl == DRAW_CURSOR ? &s->face->xft_fg : 
&s->face->xft_bg,
                     s->x,
                     s->y,
                     s->width + s->right_overhang,
                     s->height);

Remove the if-statement so the XftDrawRect is always done.  That should 
improve things, but also slow drawing down somewhat.

Thanks for pointing this out,

    Jan D.

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

* Re: Antialiased text on X11
  2005-03-29 18:24                           ` Henrik Enberg
@ 2005-03-29 22:50                             ` Miles Bader
  2005-03-31  2:42                               ` James Cloos
  0 siblings, 1 reply; 44+ messages in thread
From: Miles Bader @ 2005-03-29 22:50 UTC (permalink / raw)
  Cc: Emacs-Devel Devel, Jan D., Geoffrey J. Teale, miles

On Tue, 29 Mar 2005 20:24:34 +0200, Henrik Enberg
<henrik.enberg@telia.com> wrote:
> > [There are some other odd effects like color fringing that make me
> > wonder if it's assuming a white background.]
> 
> that might be your setup. fontconfig has options for how colors should
> be blended, and in my experience it's basically impossible to get a good
> setup for both dark text/light background and vice versa.

Er, well all my _other_ fontconfig/freetype/xft using windows (with
black or black-ish backgrounds) look absolutely fabulous, so I'd point
the finger at Emacs...

[I didn't change anything in the fontconfig setup so it seems the
default settings -- which are presumably aimed at white backgrounds --
deals pretty well with black backgrounds too.]

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-29 22:50                             ` Miles Bader
@ 2005-03-31  2:42                               ` James Cloos
  2005-03-31  4:22                                 ` Miles Bader
  0 siblings, 1 reply; 44+ messages in thread
From: James Cloos @ 2005-03-31  2:42 UTC (permalink / raw)
  Cc: miles

>>>>> "Miles" == Miles Bader <snogglethorpe@gmail.com> writes:

Miles> [I didn't change anything in the fontconfig setup so it seems
Miles> the default settings -- which are presumably aimed at white
Miles> backgrounds -- deals pretty well with black backgrounds too.]

It does depend on the font and whether you are using the byte code
interpreter.  The well-instructed fonts tend to use single-pixel
wide stems up to circa 16–18 ppem.  The auto-fitter, however,
tends to result in wider stems.  Xft’s rgba filter is tuned for
light backgrounds; single-pixel stems tend to drop out when it is
used with dark backgrounds.

So, if you are using sub-pixel rendering, the BCI and a well
instructed font you will see *much* better text with a light
background than with a dark.  But if you are using fonts w/o
quality instructions — whether poorly-instructed fonts, non-
ttf fonts, or freetype compiled w/o the interpreter — and/or
greyscale rather than sub-pixel then light on dark should be
almost as good as dark on light text.

Or at least that is what I saw back when I tested it.

-JimC
-- 
James H. Cloos, Jr. <cloos@jhcloos.com>

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

* Re: Antialiased text on X11
  2005-03-31  2:42                               ` James Cloos
@ 2005-03-31  4:22                                 ` Miles Bader
  0 siblings, 0 replies; 44+ messages in thread
From: Miles Bader @ 2005-03-31  4:22 UTC (permalink / raw)
  Cc: miles, Emacs Devel

On Mar 31, 2005 11:42 AM, James Cloos <cloos@jhcloos.com> wrote:
> So, if you are using sub-pixel rendering, the BCI and a well
> instructed font you will see *much* better text with a light
> background than with a dark.  But if you are using fonts w/o
> quality instructions — whether poorly-instructed fonts, non-
> ttf fonts, or freetype compiled w/o the interpreter — and/or
> greyscale rather than sub-pixel then light on dark should be
> almost as good as dark on light text.
> 
> Or at least that is what I saw back when I tested it.

Well, freetype has certainly improved _dramatically_ in recent times.

I use sub-pixel rendering on an LCD, and both hinted fonts (e.g.,
microsoft's stuff, the vera fonts) and non-hinted latin fonts look
quite spectacularly good -- almost every line you'd want to be 1-pixel
wide is almost exactly that, with no obvious fringing, fuzziness, or
non-uniformity, and there's no over-lightness or dropouts at all on a
black background.  While writing this message I tried comparing the
same text in the same font (using a few fonts), and the apparent
weight looks pretty much exactly the same on a black or a white
background.  [Whereas I've noticed that MS's font-rendering actually
does look fairly crappy on a black background.]

For many fonts, much of this goodness seems to be due to the
auto-hinter (which is unfortunately turned off by default).

Basically freetype seems to the point these days where it seems as
good or better than the (much crowed about) font rendering in windows
or OSX.  Certainly there are always details to make better, but ...
it's really, really, good.

-Miles
-- 
Do not taunt Happy Fun Ball.

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

* Re: Antialiased text on X11
  2005-03-29 19:28                         ` Jan D.
@ 2005-04-01  8:15                           ` Miles Bader
  2005-04-01 16:09                             ` Jan D.
  0 siblings, 1 reply; 44+ messages in thread
From: Miles Bader @ 2005-04-01  8:15 UTC (permalink / raw)
  Cc: Geoffrey J. Teale, Emacs-Devel Devel

BTW Jan, would you accept patches for your xft branch, or do you want to
work solo on this for a while?

[If patches are OK, would it be better to send you patch files or just
commit changes directly to the branch (well the latter obviously only
for straight-forward changes)?]

Thanks,

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

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

* Re: Antialiased text on X11
  2005-04-01  8:15                           ` Miles Bader
@ 2005-04-01 16:09                             ` Jan D.
  0 siblings, 0 replies; 44+ messages in thread
From: Jan D. @ 2005-04-01 16:09 UTC (permalink / raw)
  Cc: Geoffrey J. Teale, Emacs-Devel Devel

> BTW Jan, would you accept patches for your xft branch, or do you want 
> to
> work solo on this for a while?
>
> [If patches are OK, would it be better to send you patch files or just
> commit changes directly to the branch (well the latter obviously only
> for straight-forward changes)?]

Just commit them to the branch so they don't get forgotten.  I'll 
review them from there when I resume that work.

	Jan D.

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

end of thread, other threads:[~2005-04-01 16:09 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-03-10 21:45 Antialiased text on X11 James Cloos
2005-03-10 22:25 ` Stefan Monnier
2005-03-10 23:15   ` Han Boetes
2005-03-11  4:58     ` Jan D.
2005-03-18 21:21     ` Ali Ijaz Sheikh
2005-03-18 22:39       ` Drew Adams
2005-03-19 22:45         ` The WHY of Xft [was: Re: Antialiased text on X11] James Cloos
2005-03-19 23:47           ` Miles Bader
2005-03-20 16:49             ` The WHY of Xft James Cloos
2005-03-20 22:30               ` Miles Bader
2005-03-21 14:24                 ` David Hansen
2005-03-21 16:12                 ` James Cloos
2005-03-21  0:32               ` Kenichi Handa
2005-03-19  0:59       ` Antialiased text on X11 Miles Bader
2005-03-19  6:27         ` Jan D.
2005-03-19  7:39           ` Miles Bader
2005-03-19 16:31           ` Stefan Monnier
2005-03-19 16:53             ` Han Boetes
2005-03-20 11:51               ` Jan D.
2005-03-19 21:41             ` Miles Bader
2005-03-20 13:15             ` Jan D.
2005-03-20 22:51             ` Jan D.
2005-03-22 23:44               ` Miles Bader
2005-03-23  2:30                 ` Miles Bader
2005-03-23 17:50                 ` Jan D.
2005-03-25 21:40                   ` Miles Bader
2005-03-26  8:13                     ` Jan D.
2005-03-29 10:52                       ` Geoffrey J. Teale
2005-03-29 11:28                         ` Miles Bader
2005-03-29 12:24                           ` Geoffrey J. Teale
2005-03-29 18:24                           ` Henrik Enberg
2005-03-29 22:50                             ` Miles Bader
2005-03-31  2:42                               ` James Cloos
2005-03-31  4:22                                 ` Miles Bader
2005-03-29 19:28                         ` Jan D.
2005-04-01  8:15                           ` Miles Bader
2005-04-01 16:09                             ` Jan D.
2005-03-22 12:45           ` Oliver Scholz
2005-03-22 14:21             ` Stefan
2005-03-22 14:29               ` Oliver Scholz
2005-03-22 15:17                 ` David Kastrup
2005-03-10 23:19   ` James Cloos
2005-03-11  9:20     ` Geoffrey J. Teale
2005-03-11 15:13       ` Jan D.

Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).