23.0.60; broken mouse-face highlighting in Gnus

23.0.60; broken mouse-face highlighting in Gnus

[Stephen Berman]

1. emacs -Q
2. Eval this:
   (setq gnus-summary-line-format "%U%R%z%((%4L) %-20,20f \x2502 %*%B%s%)\n"
	  gnus-sum-thread-tree-root "\x25b6 "
	  gnus-sum-thread-tree-false-root "\x25b7 "
	  gnus-sum-thread-tree-vertical "\x2502 "
	  gnus-sum-thread-tree-leaf-with-other "\x251c\x2500\x25b8 ..."
	  gnus-sum-thread-tree-single-leaf "\x2570\x2500\x25b8 ...")
3. M-x gnus, browse a group that has threaded messages and see the fancy
threading display produced by the above settings in the Summary buffer.
4. Select a subject header in the Summary buffer, such that the subject
contains one of the fancy threading characters, or one of the strings
"Re: ", "RE: ", "23.", "2.", and place the cursor on one of these
characters (on the first character in the strings "Re: ", "RE: ", "23.",
"2.").
5. Move the mouse over the subject header and observe the highlighting
everywhere except the character after the cursor (in the case of
"\x251c\x2500\x25b8 ..." and "\x2570\x2500\x25b8 ...", if the cursor is
over "\x2500", the both the immediately preceding and immediately
following characters are not highlighted).

Repeat the above in Emacs 23.0.50 but with the following settings in
step 2 (since the above are invalid characters in pre-unicode-2 Emacs):
   (setq gnus-summary-line-format "%U%R%z%((%4L) %-20,20f \x49022 %*%B%s%)\n"
	    gnus-sum-thread-tree-root "\x490f6 "
	    gnus-sum-thread-tree-false-root "\x490f7 "
	    gnus-sum-thread-tree-leaf-with-other "\x4903c\x49020\x490fa ..."
	    gnus-sum-thread-tree-vertical "\x49022"
	    gnus-sum-thread-tree-single-leaf "\x490b0\x49020\x490fa ...")
Now at step 5 the entire subject shows mouse-face highlighting as it
should, i.e. no gaps.

Steve Berman

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Stephen Berman]

On Mon, 11 Feb 2008 16:47:28 +0100 Stephen Berman <Stephen.Berman@gmx.net> wrote:

> 1. emacs -Q
> 2. Eval this:
>    (setq gnus-summary-line-format "%U%R%z%((%4L) %-20,20f \x2502 %*%B%s%)\n"
> 	  gnus-sum-thread-tree-root "\x25b6 "
> 	  gnus-sum-thread-tree-false-root "\x25b7 "
> 	  gnus-sum-thread-tree-vertical "\x2502 "
> 	  gnus-sum-thread-tree-leaf-with-other "\x251c\x2500\x25b8 ..."
> 	  gnus-sum-thread-tree-single-leaf "\x2570\x2500\x25b8 ...")
> 3. M-x gnus, browse a group that has threaded messages and see the fancy
> threading display produced by the above settings in the Summary buffer.
> 4. Select a subject header in the Summary buffer, such that the subject
> contains one of the fancy threading characters, or one of the strings
> "Re: ", "RE: ", "23.", "2.", and place the cursor on one of these
> characters (on the first character in the strings "Re: ", "RE: ", "23.",
> "2.").
> 5. Move the mouse over the subject header and observe the highlighting
> everywhere except the character after the cursor (in the case of
> "\x251c\x2500\x25b8 ..." and "\x2570\x2500\x25b8 ...", if the cursor is
> over "\x2500", the both the immediately preceding and immediately
> following characters are not highlighted).
>
> Repeat the above in Emacs 23.0.50 but with the following settings in
> step 2 (since the above are invalid characters in pre-unicode-2 Emacs):
>    (setq gnus-summary-line-format "%U%R%z%((%4L) %-20,20f \x49022 %*%B%s%)\n"
> 	    gnus-sum-thread-tree-root "\x490f6 "
> 	    gnus-sum-thread-tree-false-root "\x490f7 "
> 	    gnus-sum-thread-tree-leaf-with-other "\x4903c\x49020\x490fa ..."
> 	    gnus-sum-thread-tree-vertical "\x49022"
> 	    gnus-sum-thread-tree-single-leaf "\x490b0\x49020\x490fa ...")
> Now at step 5 the entire subject shows mouse-face highlighting as it
> should, i.e. no gaps.

I made a mistake above: either step 1 should be this:

1'. emacs -Q -fn "Dejavu Sans Mono"

or before step 5 use set-frame-font to switch to Dejavu Sans Mono (then
it's without anti-aliasing, but that does not matter).  Other Dejavu
fonts also show the gap in highlighting, but the range of susceptible
strings seems to be less than with Dejavu Sans Mono.  I have tried using
a number of other fonts but so far haven't found any others that show
the display problem.

Steve Berman

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Johan Bockgård]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> Other Dejavu fonts also show the gap in highlighting, but the range of
> susceptible strings seems to be less than with Dejavu Sans Mono.  I
> have tried using a number of other fonts but so far haven't found any
> others that show the display problem.

The problem happens for characters that stick out of their box.  It is
most noticeable with an italic font.

E.g. try

    (font-lock-mode 0)
    (insert (propertize "XXXXXX" 'face 'italic 'mouse-face 'highlight))


The responsible code is this part in `draw_glyphs':

   /* If there are any glyphs with lbearing < 0 or rbearing > width in
      the row, redraw some glyphs in front or following the glyph
      strings built above.  */
  if (head && !overlaps && row->contains_overlapping_glyphs_p)
     {
       ...

-- 
Johan Bockgård

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Stephen Berman]

On Sun, 17 Feb 2008 01:40:58 +0100 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> Other Dejavu fonts also show the gap in highlighting, but the range of
>> susceptible strings seems to be less than with Dejavu Sans Mono.  I
>> have tried using a number of other fonts but so far haven't found any
>> others that show the display problem.
>
> The problem happens for characters that stick out of their box.  It is
> most noticeable with an italic font.
>
> E.g. try
>
>     (font-lock-mode 0)
>     (insert (propertize "XXXXXX" 'face 'italic 'mouse-face 'highlight))

I had also tried an italic Dejavu and it showed the problem but, as I
said, not with as many strings; here's a case in point:

(progn (font-lock-mode 0)
  (insert (propertize "Re: 23.0.60" 'mouse-face 'highlight))
  (insert (propertize "Re: 23.0.60" 'face 'italic 'mouse-face 'highlight)))

I see a gap in mouse-face highlighting when the cursor is over the
unitalicized "R" and "2" but not when it is over the italicized ones.
Do you see that too?  This seems contrary to you characterization of the
triggering conditions, i.e. characters that stick out of their box, but
I do not know the properties of the font nor understand the code you
pointed to, so maybe it is no contradiction.

> The responsible code is this part in `draw_glyphs':
>
>    /* If there are any glyphs with lbearing < 0 or rbearing > width in
>       the row, redraw some glyphs in front or following the glyph
>       strings built above.  */
>   if (head && !overlaps && row->contains_overlapping_glyphs_p)
>      {
>        ...

How did you figure this out?  Do you just know the code well and realize
that draw_glyphs was involved, or did you arrive there by using gdb?  If
the latter, could you tell me how you did it?  That might help me make
more useful bug reports and perhaps even suggest bug fixes.

Steve Berman

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Johan Bockgård]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> I had also tried an italic Dejavu and it showed the problem but, as I
> said, not with as many strings; here's a case in point:
>
> (progn (font-lock-mode 0)
>   (insert (propertize "Re: 23.0.60" 'mouse-face 'highlight))
>   (insert (propertize "Re: 23.0.60" 'face 'italic 'mouse-face 'highlight)))
>
> I see a gap in mouse-face highlighting when the cursor is over the
> unitalicized "R" and "2" but not when it is over the italicized ones.
> Do you see that too?  This seems contrary to you characterization of the
> triggering conditions, i.e. characters that stick out of their box, but
> I do not know the properties of the font nor understand the code you
> pointed to, so maybe it is no contradiction.

Well, when I try this I notice a problem with highlighting next to the
cursor to the right of the R in the non-italic case and to the left of
the 3 in the italic case.  (Going from unslanted to slanted makes the
lower right of "R" extend less, while OTOH slanting "3" makes the lower
curve protrude to the left.)  I haven't examined the font in detail, but
in any case `contains_overlapping_glyphs_p' is the relevant variable.

The problem goes away if you add a `&& hl == DRAW_NORMAL_TEXT' test to
the conditional below (but I don't think this fix is entirely right.)

>> The responsible code is this part in `draw_glyphs':
>>
>>    /* If there are any glyphs with lbearing < 0 or rbearing > width in
>>       the row, redraw some glyphs in front or following the glyph
>>       strings built above.  */
>>   if (head && !overlaps && row->contains_overlapping_glyphs_p)
>>      {
>>        ...
>
> How did you figure this out?  Do you just know the code well and realize
> that draw_glyphs was involved, or did you arrive there by using gdb?  If
> the latter, could you tell me how you did it?  That might help me make
> more useful bug reports and perhaps even suggest bug fixes.

Actually, I had already discovered another problem with precisely this
code that I had been planning to report.  That one also involved display
problems around the (box) cursor, which led me to x_draw_window_cursor
-> draw_phys_cursor_glyph -> draw_glyphs (with hl=DRAW_CURSOR;
similarly, mouse-face highlighting is produced by draw_glyphs with
hl=DRAW_MOUSE_FACE).  (I was somewhat familiar with the box cursor
drawing code, http://article.gmane.org/gmane.emacs.devel/81652.)  gdb
helped revealing the difference between the working and non-working
cases (contains_overlapping_glyphs_p).

-- 
Johan Bockgård

Bad drawing of xft fonts overlapping box cursor

[Johan Bockgård]

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

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Actually, I had already discovered another problem with precisely this
> code

   [draw_glyphs]
   /* If there are any glyphs with lbearing < 0 or rbearing > width in
      the row, redraw some glyphs in front or following the glyph
      strings built above.  */

> that I had been planning to report.

So here is that report:

In some fonts certain characters can produce overlaps with the box
cursor.  This leads to uglily drawn characters.

    emacs -Q -xrm \
      'emacs*font: bitstream vera sans mono:pixelsize=17
       Xft.hintstyle: hintmedium' \
      -fg white -bg black -cr green

    (progn
      (switch-to-buffer "*test*")
      (insert "W\nW\nW")
      (dotimes (_ 50)
        (redisplay)
        (goto-char 4)
        (redisplay)
        (goto-char 6)))

It looks like what happens is that each time the cursor is placed next
to the problematic character another copy of the character is drawn.
For antialiased fonts this produces the effect that the half transparent
pixels become more and more solid.


[-- Attachment #2: emacs-badfont.png --]
[-- Type: image/png, Size: 1815 bytes --]

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


-- 
Johan Bockgård

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Stephen Berman]

On Sun, 17 Feb 2008 21:25:18 +0100 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote:

> Stephen Berman <Stephen.Berman@gmx.net> writes:
>
>> I had also tried an italic Dejavu and it showed the problem but, as I
>> said, not with as many strings; here's a case in point:
>>
>> (progn (font-lock-mode 0)
>>   (insert (propertize "Re: 23.0.60" 'mouse-face 'highlight))
>>   (insert (propertize "Re: 23.0.60" 'face 'italic 'mouse-face 'highlight)))
>>
>> I see a gap in mouse-face highlighting when the cursor is over the
>> unitalicized "R" and "2" but not when it is over the italicized ones.
>> Do you see that too?  This seems contrary to you characterization of the
>> triggering conditions, i.e. characters that stick out of their box, but
>> I do not know the properties of the font nor understand the code you
>> pointed to, so maybe it is no contradiction.
>
> Well, when I try this I notice a problem with highlighting next to the
> cursor to the right of the R in the non-italic case and to the left of
> the 3 in the italic case.  (Going from unslanted to slanted makes the
> lower right of "R" extend less, while OTOH slanting "3" makes the lower
> curve protrude to the left.)  

It sounds likes like you're describing a subtle problem with the drawing
of the italic characters; perhaps, but I don't see any problem with
highlighting in the italicized text, while in the unitalicized test,
when the cursor is over the "R" the following "e" lacks mouse-face
highlighting, likewise with "3" when the cursor is over the "2".

Anyway, I have some additional observations:

- The highlighting gap only occurs with the filled box cursor-type, not
  with hollow, bar (not even with type '(bar . 10), which appears to
  have the same extent as the box cursor with 12 point Dejavu), or
  hbar.  However, with '(hbar . 8) and higher height values, putting the
  cursor over the first "R", which is at (point-min) does not show the
  highlighting gap, but then typing C-b or <left> does make the gap
  appear over the following "e".

- When I eval the above sexp (or just the unitalicized part) with 14
  point Dejavu, and then move the cursor from the end to the beginning,
  the gap appears over the "3" when the cursor is over the "2", and
  remains as the cursor continues to the left, until it is over the "R"
  at (point-min), and then there is a highlighting gap over the the "e"
  and the "3".  Now typing C-b or <left> eliminates the gap over the "3"
  (but the one over the "e" remains).  I do not see the double gap with
  12 point Dejavu.

- For kicks I tried the above sexp with the font settings you gave in
  your followup posting, i.e.: emacs -Q -xrm 'emacs*font: bitstream vera
  sans mono:pixelsize=17'.  With this, I see no highlighting gap with
  the unitalicized text (Bitstream Vera and Dejavu differ here), but the
  italicized text shows strange redisplay effects under mouse-face
  highlighting.  First, my system appears to lack an italicized 17 point
  Bitstream Vera Sans, and the italicized text is in 12 point.  When I
  put the mouse over the text to hightlight it, the italicized text
  loses its slant and also takes up much less horizontal space, as if
  condensed.  But when I start to move the cursor over the italicized
  (but under highlighting not italicized) text, then the original
  spacing replaces the condensed spacing character by character.

>                               I haven't examined the font in detail, but
> in any case `contains_overlapping_glyphs_p' is the relevant variable.

> The problem goes away if you add a `&& hl == DRAW_NORMAL_TEXT' test to
> the conditional below (but I don't think this fix is entirely right.)
>
>>> The responsible code is this part in `draw_glyphs':
>>>
>>>    /* If there are any glyphs with lbearing < 0 or rbearing > width in
>>>       the row, redraw some glyphs in front or following the glyph
>>>       strings built above.  */
>>>   if (head && !overlaps && row->contains_overlapping_glyphs_p)
>>>      {
>>>        ...
>>
>> How did you figure this out?  Do you just know the code well and realize
>> that draw_glyphs was involved, or did you arrive there by using gdb?  If
>> the latter, could you tell me how you did it?  That might help me make
>> more useful bug reports and perhaps even suggest bug fixes.
>
> Actually, I had already discovered another problem with precisely this
> code that I had been planning to report.  That one also involved display
> problems around the (box) cursor, which led me to x_draw_window_cursor
> -> draw_phys_cursor_glyph -> draw_glyphs (with hl=DRAW_CURSOR;
> similarly, mouse-face highlighting is produced by draw_glyphs with
> hl=DRAW_MOUSE_FACE).  (I was somewhat familiar with the box cursor
> drawing code, http://article.gmane.org/gmane.emacs.devel/81652.)  gdb
> helped revealing the difference between the working and non-working
> cases (contains_overlapping_glyphs_p).

Thanks for the details.

Steve Berman

Re: Bad drawing of xft fonts overlapping box cursor

[Stephen Berman]

On Sun, 17 Feb 2008 21:47:13 +0100 bojohan+news@dd.chalmers.se (Johan Bockgård) wrote:

> In some fonts certain characters can produce overlaps with the box
> cursor.  This leads to uglily drawn characters.
>
>     emacs -Q -xrm \
>       'emacs*font: bitstream vera sans mono:pixelsize=17
>        Xft.hintstyle: hintmedium' \
>       -fg white -bg black -cr green
>
>     (progn
>       (switch-to-buffer "*test*")
>       (insert "W\nW\nW")
>       (dotimes (_ 50)
>         (redisplay)
>         (goto-char 4)
>         (redisplay)
>         (goto-char 6)))
>
> It looks like what happens is that each time the cursor is placed next
> to the problematic character another copy of the character is drawn.
> For antialiased fonts this produces the effect that the half transparent
> pixels become more and more solid.

When I try this I do not see any difference in the "W"s.  I also tried
with 500 repetitions and I magnified the screen display, but all three
characters look identical.  This is on GNU Emacs 23.0.60.5
(i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2008-02-14 on escher running
under openSUSE 10.3.

Steve Berman

Re: Bad drawing of xft fonts overlapping box cursor

[Jason Rumney]

On Sun, 17 Feb 2008 21:47:13 +0100 bojohan+news@dd.chalmers.se (Johan 
Bockgård) wrote:
> In some fonts certain characters can produce overlaps with the box
> cursor.  This leads to uglily drawn characters.
>   

When investigating whether the new font backend had made a particular 
cursor display bug on Windows disappear a few months back, I noticed 
that the old font code is still used for drawing box cursors. As far as 
I could tell, that was the case on all platforms. I didn't get a 
response to the mail where I mentioned it, so I don't know whether it is 
an oversight or a known TODO, and whether it has since been fixed. It 
might be worth setting a breakpoint in the box cursor drawing code in 
xterm.c and see if it is hit, and how it ends up drawing the text.

Re: 23.0.60; Deja vu font breaks mouse-face highlighting in Gnus

[Johan Bockgård]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> - The highlighting gap only occurs with the filled box cursor-type,
> not with hollow, bar (not even with type '(bar . 10), which appears to
> have the same extent as the box cursor with 12 point Dejavu), or hbar.

Only the box cursor is drawn by draw_glyphs.

-- 
Johan Bockgård