Terrible underline

Terrible underline

[Lennart Borgman (gmail)]

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

I get terrible underlines with CVS Emacs 23, see the attached picture. I 
guess this has something to do with the new font handling, or?

[-- Attachment #2: terrible-underline.png --]
[-- Type: image/png, Size: 9692 bytes --]

Re: Terrible underline

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I get terrible underlines with CVS Emacs 23, see the attached
> picture. I guess this has something to do with the new font handling,
> or?

They look fine to me.  Have you looked at the screenshot?  Maybe it
captures the way things should look rather than how they actually do?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Terrible underline

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> I get terrible underlines with CVS Emacs 23, see the attached
>> picture. I guess this has something to do with the new font handling,
>> or?
> 
> They look fine to me.  Have you looked at the screenshot?  Maybe it
> captures the way things should look rather than how they actually do?

Thanks, yes I looked at the screen shot. There is no space between the 
characters and the underline. To me that is nearly unreadable.

It looked much better before the merge I think.

Re: Terrible underline

[David De La Harpe Golden]

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

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> I get terrible underlines with CVS Emacs 23, see the attached
>> picture. I guess this has something to do with the new font handling,
>> or?
> 
> They look fine to me.  Have you looked at the screenshot?  Maybe it
> captures the way things should look rather than how they actually do?
> 

Lennart's screenshot doesn't look good to me - it's underline merges
with the character bases (and doesn't break for the p descender like it
should if the underline is crossing it, but that's a more subtle issue).

However, it's probably font-dependent and font-size dependent.   I
imagine emacs could be using some metrics from the font to decide where
to position the underline...  And there's also a quantisation issue - at
small font pixel sizes, the "natural" position for an underline could
have to be distorted to match the pixel grid for a sharp, detached
underline.

Lennart, you might just try a different font and/or bigger font size,
see if the underline detaches from the bases...

Attached is what underline looks like on an out-of-box cvs build on my
system (which is apparently defaulting to bitstream vera sans.  In fact,
I can't seem to stop it using bitstream vera sans at the moment, but
that's another issue, see bug #35).

As you can see, it's not quite perfect (due to aforementioned descender
issues), but much nicer than Lennart's screenshot.













[-- Attachment #2: emacs_underline_sample.png --]
[-- Type: image/png, Size: 20884 bytes --]

Re: Terrible underline

[Lennart Borgman (gmail)]

David De La Harpe Golden wrote:
> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> I get terrible underlines with CVS Emacs 23, see the attached
>>> picture. I guess this has something to do with the new font handling,
>>> or?
>> They look fine to me.  Have you looked at the screenshot?  Maybe it
>> captures the way things should look rather than how they actually do?
>>
> 
> Lennart's screenshot doesn't look good to me - it's underline merges
> with the character bases (and doesn't break for the p descender like it
> should if the underline is crossing it, but that's a more subtle issue).
> 
> However, it's probably font-dependent and font-size dependent.   I
> imagine emacs could be using some metrics from the font to decide where
> to position the underline...  And there's also a quantisation issue - at
> small font pixel sizes, the "natural" position for an underline could
> have to be distorted to match the pixel grid for a sharp, detached
> underline.
> 
> Lennart, you might just try a different font and/or bigger font size,
> see if the underline detaches from the bases...
> 
> Attached is what underline looks like on an out-of-box cvs build on my
> system (which is apparently defaulting to bitstream vera sans.  In fact,
> I can't seem to stop it using bitstream vera sans at the moment, but
> that's another issue, see bug #35).
> 
> As you can see, it's not quite perfect (due to aforementioned descender
> issues), but much nicer than Lennart's screenshot.

Thanks David, the underline looks quite good to my on your screen shot. 
It used to look the same (nearly) for me. I believe it is something that 
has happened after the merge that has changed this. (BTW I am using w32 
which probably is important information here.)

Re: Terrible underline

[Francesc Rocher]

> "Lennart Borgman (gmail)" <address@hidden> writes:
>> David Kastrup wrote:
>>>    "Lennart Borgman (gmail)" <address@hidden> writes:
>>>
>>>        I get terrible underlines with CVS Emacs 23, see the attached
>>>        picture. I guess this has something to do with the new font handling,
>>>        or?
>>
>>    They look fine to me.  Have you looked at the screenshot?  Maybe it
>>    captures the way things should look rather than how they actually do?
>>
> Thanks, yes I looked at the screen shot. There is no space
> between the characters and the underline. To me that is nearly
> unreadable.
>
> It looked much better before the merge I think.

Yes, you're right. It's time to get support for the variable
'x-underline-at-descent-line' under win32. Before the merge it
was not necessary, but now this patch should be installed:

---8<------8<------8<------8<------8<------8<------8<------8<---
--- w32term.c   3 Mar 2008 06:32:12 -0000       1.284
+++ w32term.c   8 Mar 2008 18:50:46 -0000
@@ -2950,11 +2950,13 @@
 #ifdef USE_FONT_BACKEND
          if (enable_font_backend)
            {
-             if (s->face->font)
-               /* In the future, we must use information of font.  */
-               y = s->ybase + (s->face->font->max_bounds.descent + 1) / 2;
-             else
-               y = s->y + s->height - h;
+             y = s->y + s->height - h;
+             if (!x_underline_at_descent_line)
+               {
+                 if (s->face->font)
+                   /* In the future, we must use information of font.  */
+                   y = s->ybase + (s->face->font->max_bounds.descent + 1) / 2;
+               }
            }
          else
 #endif
---8<------8<------8<------8<------8<------8<------8<------8<---

Then,

   (setq x-underline-at-descent-line t)

should make the underlining readable (it should look as before).

Please note that I have no write access to CVS so, if approved, the patch
should be updated by some maintainer.

-- 
Francesc Rocher

Re: Terrible underline

[David Kastrup]

"Francesc Rocher" <francesc.rocher@gmail.com> writes:

>> "Lennart Borgman (gmail)" <address@hidden> writes:
>>> David Kastrup wrote:
>>>>    "Lennart Borgman (gmail)" <address@hidden> writes:
>>>>
>>>>        I get terrible underlines with CVS Emacs 23, see the attached
>>>>        picture. I guess this has something to do with the new font handling,
>>>>        or?
>>>
>>>    They look fine to me.  Have you looked at the screenshot?  Maybe it
>>>    captures the way things should look rather than how they actually do?
>>>
>> Thanks, yes I looked at the screen shot. There is no space
>> between the characters and the underline. To me that is nearly
>> unreadable.
>>
>> It looked much better before the merge I think.
>
> Yes, you're right. It's time to get support for the variable
> 'x-underline-at-descent-line' under win32. Before the merge it
> was not necessary, but now this patch should be installed:

[...]

> Then,
>
>    (setq x-underline-at-descent-line t)
>
> should make the underlining readable (it should look as before).

Why would one want to have an option then?  Can you think of a use case
where people would want to have it set to nil?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Terrible underline

[Francesc Rocher]

On Sat, Mar 8, 2008 at 10:02 PM, David Kastrup <dak@gnu.org> wrote:
> "Francesc Rocher" <francesc.rocher@gmail.com> writes:
>
>  >> "Lennart Borgman (gmail)" <address@hidden> writes:
>  >>> David Kastrup wrote:
>  >>>>    "Lennart Borgman (gmail)" <address@hidden> writes:
>  >>>>
>  >>>>        I get terrible underlines with CVS Emacs 23, see the attached
>  >>>>        picture. I guess this has something to do with the new font handling,
>  >>>>        or?
>  >>>
>  >>>    They look fine to me.  Have you looked at the screenshot?  Maybe it
>  >>>    captures the way things should look rather than how they actually do?
>  >>>
>  >> Thanks, yes I looked at the screen shot. There is no space
>  >> between the characters and the underline. To me that is nearly
>  >> unreadable.
>  >>
>  >> It looked much better before the merge I think.
>  >
>  > Yes, you're right. It's time to get support for the variable
>  > 'x-underline-at-descent-line' under win32. Before the merge it
>  > was not necessary, but now this patch should be installed:
>
>  [...]
>
>
>  > Then,
>  >
>  >    (setq x-underline-at-descent-line t)
>  >
>  > should make the underlining readable (it should look as before).
>
>  Why would one want to have an option then?  Can you think of a use case
>  where people would want to have it set to nil?
>
>  --
>  David Kastrup, Kriemhildstr. 15, 44793 Bochum
>

This variable was introduced to force the drawing of the underline
line at the descent line. Please note that the variable
'x-use-underline-position-properties' can make use of the font
properties, but by default the underline line is drawn at the base
line (don't try to use it under win32, it isn't supported yet). I
think the better would be to use the font properties and, probably, to
remove both variables. The question is whether all fonts have reliable
values about the position and width of the underline line.


-- 
Francesc Rocher