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

[Vincent Lefevre <vincent@vinc17.net>]

On 2020-11-01 19:43:12 +0200, Eli Zaretskii wrote:
> > When the cache is filled with
> > 
> >       cache->ascent = ceil (- extents.y_bearing);
> > 
> > extents.y_bearing (whose type is double) is equal to:
> > 
> > Font size 13: -0x1.6000000000001p+3 ≈ -11.000000000000002
> > Font size 14: -0x1.8p+3 = -12
> > 
> > With ceil(), 11.000000000000002 rounds to 12, while the expected value
> > is 11. A rounding issue, as I guessed at
> > 
> >   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44284#29
> 
> 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.

If I understand correctly, Cairo can handle any font size (not just
integer ones), e.g. with scalable fonts. Thus rounding cannot be
avoided. Ideally one should have correct rounding on each visible
result, but I suppose that this can be very complex and slow down
applications, so that in general, an indeterminate rounding error
may be acceptable, and applications / rendering algorithms should
cope with that (when discontinuous functions are involved, such as
rounding to an integer): if continuity is preserved in some way,
the user will never see an error of, say, 2^(-45) pixel.

Now, there's the particular case of integer font sizes, in particular
with X fonts, and one may want to preserve integers exactly on the
Cairo side. I don't know whether this can be done or there are tricky
issues.

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?

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

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?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)