bug#5679: Emacs 23.1.93 pretest

bug#5679: Emacs 23.1.93 pretest

[Sergei Organov]

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

Chong Yidong <cyd@stupidchicken.com> writes:

> Emacs pretest 23.1.93 is now available for download via FTP,

It incorrectly renders terminus oblique fonts from Debian distribution
(xfonts-terminus-oblique Debian package):

-xos4-terminus-medium-o-*
-xos4-terminus-bold-o-*

Small example screenshots from emacs 22.2.1 (correct rendering) and
emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly
"Global Mark Ring" looks when rendered by emacs23.

NOTE: emacs 23.1.1 also renders wrong.


[-- Attachment #2: emacs22 correct rendering --]
[-- Type: image/png, Size: 7950 bytes --]

[-- Attachment #3: emacs23 wrong rendering --]
[-- Type: image/png, Size: 9031 bytes --]

bug#5679: Emacs 23.1.93 pretest

[Chong Yidong]

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

Sergei Organov <osv@javad.com> writes:

> It incorrectly renders terminus oblique fonts from Debian distribution
> (xfonts-terminus-oblique Debian package):
>
> -xos4-terminus-medium-o-*
> -xos4-terminus-bold-o-*
>
> Small example screenshots from emacs 22.2.1 (correct rendering) and
> emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly
> "Global Mark Ring" looks when rendered by emacs23.
>
> NOTE: emacs 23.1.1 also renders wrong.

I can't reproduce this---see attached screenshot, taken from 23.1.93.
Please provide an exact recipe, including the exact .Xresources
specification you use to choose the font.


[-- Attachment #2: foo.png --]
[-- Type: image/png, Size: 15306 bytes --]

bug#5679: Emacs 23.1.93 pretest

[osv]

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

Chong Yidong <cyd@stupidchicken.com> writes:

> Sergei Organov <osv@javad.com> writes:
>
>> It incorrectly renders terminus oblique fonts from Debian distribution
>> (xfonts-terminus-oblique Debian package):
>>
>> -xos4-terminus-medium-o-*
>> -xos4-terminus-bold-o-*
>>
>> Small example screenshots from emacs 22.2.1 (correct rendering) and
>> emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly
>> "Global Mark Ring" looks when rendered by emacs23.
>>
>> NOTE: emacs 23.1.1 also renders wrong.
>
> I can't reproduce this---see attached screenshot, taken from 23.1.93.
> Please provide an exact recipe, including the exact .Xresources
> specification you use to choose the font.

I don't use .Xresources. What I did was faces customization through
customize. The simplest reproduction I came-up with is:

$ emacs -q --no-site-file
- Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash
  screen
- M-x customize-face <ENTER> <ENTER>
- Change "Font Family:" to "terminus"
- Select "State|Set for Current Session"
- C-x b <ENTER> to return to splash screen, and

/ABSOLUTELY NO WARRANTY/ looks like in the attached file.

Here is result of report-emacs-bug after those steps:

In GNU Emacs 23.1.93.1 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-03-04 on osv
Windowing system distributor `The X.Org Foundation', version 11.0.10705000
configured using `configure  '--prefix=/home/osv/emacs''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<down> <down> <down> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> M-x c u s t 
o m i z e - f a c e <return> <return> <help-echo> <down-mouse-1> 
<help-echo> <mouse-movement> <drag-mouse-1> C-w t e 
r m i n u s <help-echo> <help-echo> <down-mouse-1> 
C-x b <return> M-x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Creating customization items...
Creating face editor...done
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done

Load-path shadows:
/home/osv/emacs/share/emacs/site-lisp/flim/md4 hides /home/osv/emacs/share/emacs/23.1.93/lisp/md4
/home/osv/emacs/share/emacs/site-lisp/flim/sha1 hides /home/osv/emacs/share/emacs/23.1.93/lisp/sha1
/home/osv/emacs/share/emacs/site-lisp/flim/hex-util hides /home/osv/emacs/share/emacs/23.1.93/lisp/hex-util
/home/osv/emacs/share/emacs/site-lisp/flim/sasl-digest hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-digest
/home/osv/emacs/share/emacs/site-lisp/flim/sasl hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl
/home/osv/emacs/share/emacs/site-lisp/flim/sasl-cram hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-cram
/home/osv/emacs/share/emacs/site-lisp/flim/hmac-def hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/hmac-def
/home/osv/emacs/share/emacs/site-lisp/flim/ntlm hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/ntlm
/home/osv/emacs/share/emacs/site-lisp/flim/hmac-md5 hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/hmac-md5
/home/osv/emacs/share/emacs/site-lisp/flim/sasl-ntlm hides /home/osv/emacs/share/emacs/23.1.93/lisp/net/sasl-ntlm

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils mailheader canlock sha1
sha1-el hex-util hashcash mail-utils emacsbug crm thingatpt cus-edit
easymenu cus-start cus-load wid-edit tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd font-setting tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mldrag mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process
font-render-setting gtk x-toolkit x multi-tty emacs)



[-- Attachment #2: render.png --]
[-- Type: image/png, Size: 1388 bytes --]

bug#5679: Emacs 23.1.93 pretest

[Chong Yidong]

<osv@javad.com> writes:

> $ emacs -q --no-site-file
> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash
>   screen
> - M-x customize-face <ENTER> <ENTER>
> - Change "Font Family:" to "terminus"
> - Select "State|Set for Current Session"
> - C-x b <ENTER> to return to splash screen, and
>
> /ABSOLUTELY NO WARRANTY/ looks like in the attached file.

Fraid I still can't reproduce this.  One possibility I can think of is
that the particular version of terminus you are using is buggy, and
reports the right overhang incorrectly.  Strange...

bug#5679: Emacs 23.1.93 pretest

[osv]

Chong Yidong <cyd@stupidchicken.com> writes:

> <osv@javad.com> writes:
>
>> $ emacs -q --no-site-file
>> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash
>>   screen
>> - M-x customize-face <ENTER> <ENTER>
>> - Change "Font Family:" to "terminus"
>> - Select "State|Set for Current Session"
>> - C-x b <ENTER> to return to splash screen, and
>>
>> /ABSOLUTELY NO WARRANTY/ looks like in the attached file.
>
> Fraid I still can't reproduce this.  One possibility I can think of is
> that the particular version of terminus you are using is buggy, and
> reports the right overhang incorrectly.  Strange...

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?

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?

BTW, emacs 23.1.1 only breaks rendering after I move cursor over the
text. If I, for examle, select the text (active region so it's
highlighted), the rendering becomes OK. Emacs 23.1.93 is more consistent
and always renders bad.

-- Sergei.

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);
  }

bug#5679: Emacs 23.1.93 pretest

[osv]

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

>>>>>> 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)))) ?

It looks nice in the new frame, while still broken in the original frame.

>
> 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.

I'll check it a little bit later.

-- Sergei.

bug#5679: Emacs 23.1.93 pretest

[osv]

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

>>>>>> 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.

I've tried the patch. It does not fix the problem.

-- Sergei.

bug#5679: Emacs 23.1.93 pretest

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 10 Mar 2010 13:05:07 +0300, <osv@javad.com> said:

>> I tried installing the PCF fonts extracted from
>> xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X
>> 10.6.  The result was:
>> 
>> 1. I could reproduce the above problem on Emacs 23.1.92.
>> 2. But I could also reproduce it on Emacs 23.1, unlike OP.

> No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I
> wrote in the original report:

> " Small example screenshots from emacs 22.2.1 (correct rendering)
> and emacs 23.1.93 (wrong rendering) are attached. Please notice how
> ugly "Global Mark Ring" looks when rendered by emacs23.

>   NOTE: emacs 23.1.1 also renders wrong."

I meant this one:

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

> BTW, emacs 23.1.1 only breaks rendering after I move cursor over the
> text. If I, for examle, select the text (active region so it's
> highlighted), the rendering becomes OK. Emacs 23.1.93 is more
> consistent and always renders bad.

I could not find the difference between the release version and the
pretest one.

Anyway, is `xterm -fa terminus:style=oblique' also broken?  If so, we
can conclude this is not a bug at the Emacs side.

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

bug#5679: Emacs 23.1.93 pretest

[osv]

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

>>>>>> On Wed, 10 Mar 2010 13:05:07 +0300, <osv@javad.com> said:
>
>>> I tried installing the PCF fonts extracted from
>>> xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X
>>> 10.6.  The result was:
>>> 
>>> 1. I could reproduce the above problem on Emacs 23.1.92.
>>> 2. But I could also reproduce it on Emacs 23.1, unlike OP.
>
>> No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I
>> wrote in the original report:
>
>> " Small example screenshots from emacs 22.2.1 (correct rendering)
>> and emacs 23.1.93 (wrong rendering) are attached. Please notice how
>> ugly "Global Mark Ring" looks when rendered by emacs23.
>
>>   NOTE: emacs 23.1.1 also renders wrong."
>
> I meant this one:
>
>>>>>> On Thu, 04 Mar 2010 22:22:50 +0300, <osv@javad.com> said:
>
>> BTW, emacs 23.1.1 only breaks rendering after I move cursor over the
>> text. If I, for examle, select the text (active region so it's
>> highlighted), the rendering becomes OK. Emacs 23.1.93 is more
>> consistent and always renders bad.
>
> I could not find the difference between the release version and the
> pretest one.

Well, I do see this difference indeed, but both render wrong anyway, so
the difference is not essential, I think.

> Anyway, is `xterm -fa terminus:style=oblique' also broken?  If so, we
> can conclude this is not a bug at the Emacs side.

Yeah, this is broken as well. So please excuse my ignorance, but where
exactly the problem is? I.e., why emacs 22 renders it fine? What is a
work-around for emacs 23?

-- Sergei.

bug#5679: Emacs 23.1.93 pretest

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 10 Mar 2010 14:29:59 +0300, <osv@javad.com> said:

>> Anyway, is `xterm -fa terminus:style=oblique' also broken?  If so,
>> we can conclude this is not a bug at the Emacs side.

> Yeah, this is broken as well. So please excuse my ignorance, but
> where exactly the problem is?

According to the experiments so far, it seems to be caused by Xft in
addition to some conditions that are not yet sure (maybe library
versions or settings?).

> I.e., why emacs 22 renders it fine?  What is a work-around for emacs
> 23?

Emacs 22 uses the traditional text drawing aka X core fonts, and many
GNOME and GTK+ applications use cairo rather than Xft.  A workaround
would be to use the traditional text drawing as in Emacs 22 by
preferring the X core font driver to the Xft one (see `fontBackend' in
the "Table of X Resources for Emacs" node in the Emacs info).

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

bug#5679: Emacs 23.1.93 pretest

[osv]

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

>>>>>> On Wed, 10 Mar 2010 14:29:59 +0300, <osv@javad.com> said:
>
>>> Anyway, is `xterm -fa terminus:style=oblique' also broken?  If so,
>>> we can conclude this is not a bug at the Emacs side.
>
>> Yeah, this is broken as well. So please excuse my ignorance, but
>> where exactly the problem is?
>
> According to the experiments so far, it seems to be caused by Xft in
> addition to some conditions that are not yet sure (maybe library
> versions or settings?).
>
>> I.e., why emacs 22 renders it fine?  What is a work-around for emacs
>> 23?
>
> Emacs 22 uses the traditional text drawing aka X core fonts, and many
> GNOME and GTK+ applications use cairo rather than Xft.  A workaround
> would be to use the traditional text drawing as in Emacs 22 by
> preferring the X core font driver to the Xft one (see `fontBackend' in
> the "Table of X Resources for Emacs" node in the Emacs info).

OK, adding

Emacs.fontBackend:           x,xft,cairo

to my .Xdefaults fixed the problem, -- thanks a lot!

-- Sergei.

bug#5679: Emacs 23.1.93 pretest

[YAMAMOTO Mitsuharu]

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

>>>>> On Wed, 10 Mar 2010 15:12:37 +0300, <osv@javad.com> said:

>> Emacs 22 uses the traditional text drawing aka X core fonts, and
>> many GNOME and GTK+ applications use cairo rather than Xft.  A
>> workaround would be to use the traditional text drawing as in Emacs
>> 22 by preferring the X core font driver to the Xft one (see
>> `fontBackend' in the "Table of X Resources for Emacs" node in the
>> Emacs info).

> OK, adding

> Emacs.fontBackend: x,xft,cairo

> to my .Xdefaults fixed the problem, -- thanks a lot!

Currently Emacs doesn't provide the `cairo' font backend driver.
Maybe it's not harmful if specified, but you can remove it.

BTW, `xfd -fa terminus:style=oblique' would be more appropriate than
`xterm ...' for showing that it is not a bug at the Emacs side.

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

[-- Attachment #2: terminus-oblique.png --]
[-- Type: image/png, Size: 7526 bytes --]

bug#5679: Emacs 23.1.93 pretest

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 04 Mar 2010 13:06:35 -0500, Chong Yidong <cyd@stupidchicken.com> said:

> <osv@javad.com> writes:
>> $ emacs -q --no-site-file
>> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash
>> screen
>> - M-x customize-face <ENTER> <ENTER>
>> - Change "Font Family:" to "terminus"
>> - Select "State|Set for Current Session"
>> - C-x b <ENTER> to return to splash screen, and
>> 
>> /ABSOLUTELY NO WARRANTY/ looks like in the attached file.

> Fraid I still can't reproduce this.  One possibility I can think of is
> that the particular version of terminus you are using is buggy, and
> reports the right overhang incorrectly.  Strange...

I tried installing the PCF fonts extracted from
xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X 10.6.
The result was:

  1. I could reproduce the above problem on Emacs 23.1.92.
  2. But I could also reproduce it on Emacs 23.1, unlike OP.
  3. `xterm -fa terminus:style=oblique' showed the same problem.
  4. I also tried my preliminary proof-of-concept cairo port (*)
     adjusted to Emacs 23.1.91, and it didn't show the problem.  This
     explains why many GNOME and GTK+ apps don't show the problem with
     the same fonts.

So, at least for my case, a possible explanation is that it is a
problem in Xft drawing for some versions or settings.  What's not
explained is the inconsistency between the result 2 above and OP's
experience with Emacs 23.1.

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

(*) http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00390.html

bug#5679: Emacs 23.1.93 pretest

[osv]

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

>>>>>> On Thu, 04 Mar 2010 13:06:35 -0500, Chong Yidong <cyd@stupidchicken.com> said:
>
>> <osv@javad.com> writes:
>>> $ emacs -q --no-site-file
>>> - Move cursor to the /ABSOLUTELY NO WARRANTY/ text in the splash
>>> screen
>>> - M-x customize-face <ENTER> <ENTER>
>>> - Change "Font Family:" to "terminus"
>>> - Select "State|Set for Current Session"
>>> - C-x b <ENTER> to return to splash screen, and
>>> 
>>> /ABSOLUTELY NO WARRANTY/ looks like in the attached file.
>
>> Fraid I still can't reproduce this.  One possibility I can think of is
>> that the particular version of terminus you are using is buggy, and
>> reports the right overhang incorrectly.  Strange...
>
> I tried installing the PCF fonts extracted from
> xfonts-terminus-oblique_4.26-2.1_all.deb to ~/.fonts on Mac OS X 10.6.
> The result was:
>
>   1. I could reproduce the above problem on Emacs 23.1.92.
>   2. But I could also reproduce it on Emacs 23.1, unlike OP.

No, I, the OP, can also reproduce it on Emacs 23.1. Here is what I wrote
in the original report:

" Small example screenshots from emacs 22.2.1 (correct rendering) and
  emacs 23.1.93 (wrong rendering) are attached. Please notice how ugly
  "Global Mark Ring" looks when rendered by emacs23.

  NOTE: emacs 23.1.1 also renders wrong."



>   3. `xterm -fa terminus:style=oblique' showed the same problem.
>   4. I also tried my preliminary proof-of-concept cairo port (*)
>      adjusted to Emacs 23.1.91, and it didn't show the problem.  This
>      explains why many GNOME and GTK+ apps don't show the problem with
>      the same fonts.
>
> So, at least for my case, a possible explanation is that it is a
> problem in Xft drawing for some versions or settings.  What's not
> explained is the inconsistency between the result 2 above and OP's
> experience with Emacs 23.1.

Emacs 23.1 behaves slightly different for me, but it still renders
wrong, so there is no inconsistency here.

-- Sergei.