bug#5679: Emacs 23.1.93 pretest

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said:

> Yeah, it's really strange. I see it on 2 different computers running
> Debian stable and Debian testing. On both emacs23 gives this effect.
> And the fact that emacs22 renders fine means that it's probably not
> font issue, but maybe a problem of rendering library? What
> distribution do you use?

I couldn't reproduce it on Ubuntu 9.10.

> In addition I've just checked that GNOME itself renders this font
> fine both in its font selection dialog and in gnome-terminal, so the
> only place where I can see the breakage is emacs run in X. Maybe to
> compile emacs with some other options to isolate the cause of the
> problem?

It would be worth testing whether the problem is specific to a
particular font backend or not.  What happens if you replicate the
steps on a frame created with (make-frame '((font-backend . (x)))) ?

Also, could you try the following patch to see if it changes the
situation?  It is not meant to be a fix, but just for an experiment.

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

=== modified file 'src/xftfont.c'
*** src/xftfont.c       2010-01-13 08:35:10 +0000
--- src/xftfont.c       2010-03-09 00:03:12 +0000
***************
*** 795,801 ****
    xftfont_driver.text_extents = xftfont_text_extents;
    xftfont_driver.draw = xftfont_draw;
    xftfont_driver.end_for_frame = xftfont_end_for_frame;
!   xftfont_driver.cached_font_ok = xftfont_cached_font_ok;
  
    register_font_driver (&xftfont_driver, NULL);
  }
--- 795,801 ----
    xftfont_driver.text_extents = xftfont_text_extents;
    xftfont_driver.draw = xftfont_draw;
    xftfont_driver.end_for_frame = xftfont_end_for_frame;
!   xftfont_driver.cached_font_ok = 0 /*xftfont_cached_font_ok*/;
  
    register_font_driver (&xftfont_driver, NULL);
  }