GNU bug report logs - #43058
27.1; Support for other colour font formats

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: 43058 <at> debbugs.gnu.org, lists.gnu.org <at> mavit.org.uk
Subject: bug#43058: 27.1; Support for other colour font formats
Date: Thu, 22 Sep 2022 10:10:53 +0300

> Date: Thu, 22 Sep 2022 11:45:02 +0900
> From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> 	43058 <at> 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?  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?

Thanks.

Previous Next

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