bug#44284: 27.1; with some Unicode font, scrolling upward with the mouse wheel actually scrolls downward when the cursor needs repositioning

[Eli Zaretskii]

> Date: Sun, 1 Nov 2020 19:34:58 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: 44284@debbugs.gnu.org
> 
> > Thanks.  Do you have a suggestion for a fix?
> 
> Well, I think that there are 3 potential issues.
> 
> 1. That fact that here, extents.y_bearing is slightly incorrect,
> which appears to be a bug in Cairo.

Probably (I'm not an expert on Cairo), but if so, this is out of our
control.  For all I know, Cairo developers could have decided to drop
support for the font family you are using.

> 2. The fact that the cache->ascent integer gets incorrect in Emacs.
> 
> This could be fixed either on the Cairo side (see above) or on the
> application (Emacs) side. In the latter case:
> 
> First, if Emacs knows that under some condition, extents.y_bearing
> should be an integer, it could round to nearest. For instance, if
> this is an X font like here, is this necessarily the case?
> 
> Alternatively, Emacs could use some heuristic: if extents.y_bearing
> is very close to an integer, assume that it should be this integer.
> This is rather ugly as this might yield unexpected results in some
> applications, but would this be OK in Emacs?

It would be okay, I think: we have a few kludgey workarounds for
similar issues in other libraries.

I thought about something like using ceil (VALUE - 1/128) or maybe
even 1/256, on the assumption that the original integer value cannot
be of a greater granularity (the non-Cairo code uses 1/64).

> 3. The fact that row->phys_ascent > row->ascent in compute_line_metrics
> yields an incorrect behavior. This is about the following comment:
> 
>       /* If first line's physical ascent is larger than its logical
>          ascent, use the physical ascent, and make the row taller.
>          This makes accented characters fully visible.  */

This is not a bug, we must keep that code.  It just isn't supposed to
fire in your case.

> Or is the bug I've reported about that is specific to the incorrect
> cache->ascent issue (item 2), in which case fixing (2) would be
> sufficient for everyone?

Yes, we should solve item 2.

Thanks.