bug#30609: 26.0.91; underline should be drawn behind text

bug#30609: 26.0.91; underline should be drawn behind text

[Aaron Jensen]

I don't know if it's true on all platforms, but at least on the mac the
text decorations (like underlines) are drawn after the glyph causing
them to overlap the descenders. Typically underlines are drawn behind
the characters as they are less important than the characters
themselves.
I'd be happy to submit a patch to change the order if no one sees a problem with this.

Maybe some day we a text-decoration-skip equivalent, but that's a bit
beyond my capabilities at the moment :)

bug#30609: 26.0.91; underline should be drawn behind text

[Aaron Jensen]

It seems like there's a bit more to this than I thought. It looks like
ns_draw_glyph_string_foreground sometimes draws the background too,
covering the underline. It didn't do this with emacs -Q, but it did
with my config. It seems like I'd need to actually draw the background
separately, then the underline, then the glyph above. Any thoughts
about this or other suggestions?

Thanks,

Aaron

bug#30609: 26.0.91; underline should be drawn behind text

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 25 Feb 2018 15:05:29 -0800
> 
> I don't know if it's true on all platforms, but at least on the mac the
> text decorations (like underlines) are drawn after the glyph causing
> them to overlap the descenders. Typically underlines are drawn behind
> the characters as they are less important than the characters
> themselves.
> I'd be happy to submit a patch to change the order if no one sees a problem with this.

I'm far from being an expert in this area, but AFAICT, such a change
could cause the underline to become partially or even fully invisible,
at least in some situations.  For example, if the underline is to be
drawn below one or more images, or some special characters, or what we
use to display characters with no font.  That's because we sometimes
clear the entire character cell with the background color before
drawing the foreground, and that would erase the part of the underline
below that cell.  Right?

bug#30609: 26.0.91; underline should be drawn behind text

[Eli Zaretskii]

> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 25 Feb 2018 19:46:55 -0800
> 
> It seems like there's a bit more to this than I thought. It looks like
> ns_draw_glyph_string_foreground sometimes draws the background too,
> covering the underline. It didn't do this with emacs -Q, but it did
> with my config. It seems like I'd need to actually draw the background
> separately, then the underline, then the glyph above. Any thoughts
> about this or other suggestions?

Yes, this is what I feared, and that's why I think simply switching
the order will not give good results.

bug#30609: 26.0.91; underline should be drawn behind text

[Aaron Jensen]

On Mon, Feb 26, 2018 at 7:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Yes, this is what I feared, and that's why I think simply switching
> the order will not give good results.

I may be able to move the text decoration code to the font drawing,
but text decoration is done for more than fonts, so that could result
in some duplication or nsterm referencing nsfont which would then
reference nsterm. If that's ok, I can look into that.

The other option would be to move the background drawing code out of
the font rendering. I don't know all of the places that it is done, so
that may be cumbersome.

One other, completely different idea that may not work or may be
really slow would be to do a color replacement--only replacing pixels
that match the background color with the underline color. I have no
idea if reading from the canvas in this way is slow. This would end up
giving a similar effect to text-decoration-skip.

bug#30609: 26.0.91; underline should be drawn behind text

[Alan Third]

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

On 26 Feb 2018 9:11 p.m., "Aaron Jensen" <aaronjensen@gmail.com> wrote:


I may be able to move the text decoration code to the font drawing,
but text decoration is done for more than fonts, so that could result
in some duplication or nsterm referencing nsfont which would then
reference nsterm. If that's ok, I can look into that.


The NS port has two font backends: nsfont and macfont. If you make changes
you'll have to support both.

[-- Attachment #2: Type: text/html, Size: 1032 bytes --]