bug#43058: 27.1; Support for other colour font formats

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

On Thu, 22 Sep 2022 16:10:53 +0900,
Eli Zaretskii wrote:
> 
> > Date: Thu, 22 Sep 2022 11:45:02 +0900
> > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> > Cc: Eli Zaretskii <eliz@gnu.org>,
> > 	43058@debbugs.gnu.org
> > 
> > This font is rejected by the ftcr(hb) font backend because its average
> > width is computed as 0.  The average width is approximated by that of
> > all ASCII chars, and the width of glyph ID 0 is used for missing ones.
> > OpenMoji Color does not have several ASCII chars, and the width of
> > glyph ID 0 is 0.  That's why the average width becomes 0 there.
> > 
> > The patch below avoids this by taking the average of non-zero width of
> > the ASCII chars.  But glyphs are not displayed because SVG-in-OpenType
> > support in cairo is still in progress:
> > https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/319
> 
> Does this mean the patch, if installed, will not reject the font, but
> will also not display its glyphs?

Yes.

> If so, doesn't it mean we should install this patch conditioned on
> some (future) Cairo version, where these glyphs will be displayed?
> As long as Cairo doesn't support that, I think rejecting these fonts
> is the best we can do, right?

In principle, some other fonts whose formats can be handled by the
current Emacs and cairo might have been inadvertently rejected
(althogh I don't have any concrete examples).

Also, the latest version of OpenMoji Color no longer has the average
width problem.  So, it is not rejected even without the patch, and its
glyphs are not displayed on the current Emacs and cairo anyway.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp