GNU bug report logs - #54970
28.1; Some emoji no longer display

Previous Next

Full log

Message #155 received at 54970 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 54970 <at> debbugs.gnu.org, larsi <at> gnus.org, hmelman <at> gmail.com, rpluim <at> gmail.com
Subject: Re: bug#54970: 28.1; Some emoji no longer display
Date: Mon, 18 Apr 2022 20:28:29 +0100

On Mon, Apr 18, 2022 at 05:23:49PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 18 Apr 2022 14:19:24 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: larsi <at> gnus.org, hmelman <at> gmail.com, rpluim <at> gmail.com,
> > 	54970 <at> debbugs.gnu.org
> > 
> > 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.
> 
> If the y offsets are wrong, you should step through
> produce_glyphless_glyph, where they are calculated.

It turns out that ascent and descent were reversed.

This is one of the biggest problems with the GNUstep port, the ns font
backend was broken even when it was merged in and it's only got
further out of step as time has passed. No wonder the decision was
made, however long ago, to get rid of it on macOS.

Pushed to master.
-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.