GNU bug report logs -
#43058
27.1; Support for other colour font formats
Previous Next
Reported by: Peter Oliver <lists.gnu.org <at> mavit.org.uk>
Date: Wed, 26 Aug 2020 12:25:02 UTC
Severity: normal
Found in version 27.1
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Bug is archived. No further changes may be made.
Full log
Message #17 received at 43058 <at> debbugs.gnu.org (full text, mbox):
> 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.
This bug report was last modified 2 years and 242 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.