bug#54970: 28.1; Some emoji no longer display

[Alan Third]

On Mon, Apr 18, 2022 at 07:29:00AM +0300, Eli Zaretskii wrote:
> > Date: Sun, 17 Apr 2022 21:34:52 +0100
> > From: Alan Third <alan@idiocy.org>
> > 
> > >     case GLYPHLESS_GLYPH:
> > >       if (s->for_overlaps || (s->cmp_from > 0
> > >                         && ! s->first_glyph->u.cmp.automatic))
> > >         s->background_filled_p = 1;
> > >       else
> > >         ns_maybe_dumpglyphs_background
> > >           (s, s->first_glyph->type == COMPOSITE_GLYPH);
> > >       /* ... */
> > >       /* Not yet implemented.  */
> > >       /* ... */
> > >       break;
> > 
> > To answer my own question: yes. Yes it is.
> > 
> > Patch attached.
> > 
> > It doesn't look to me like it displays quite right, the right hand
> > side of the hex code gets cut off on my Mac and under GNUstep only the
> > first line is displayed, but I can't see any reason for it.
> 
> Can you show screenshots?  I'm not sure I understand the description
> of the display problems that this code yields.
> 
> The font used for the hex code should be a smaller one, and that is
> determined elsewhere in the display code, so maybe that part also
> needs some fix in the NS build?

I've changed my mind about on the Mac. The hex code isn't centred, but
it is readable.

I found a couple of bugs in nsfont.m, which is the GNUstep font
backend, and now the only problem is that the upper and lower text are
drawn in almost the same location. I suspect some error in how the
font backend is calculating the ascent and descent or something. I
don't see what's wrong, though.

Screenshot for GNUstep attached. In this example upper_yoff and
lower_yoff are -14 and -13, respectively.

Po Lu, any ideas?

-- 
Alan Third

10FFFF.png
Description: PNG image

v2-0001-Fix-glyphless-glyph-display-on-NS-bug-54970.patch
Description: Text Data