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

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

[Peter Oliver]

As I understand it, there are four competing standards for colour in TFF fonts: CBDT (Google), COLR (Microsoft), SBIX (Apple) and SVG (W3C).

I have tried CBDT, COLR and SVG in Emacs 27.1 on Fedora 32, and only CBDT works for me.

Gnome on Fedora 32 supports both CBDT and COLR, suggesting that the underlying libraries have the necessary support for COLR.

CBDT is a bitmap format, whereas COLR is a vector format; it would be good to be able to support both.  Further, the existence of https://github.com/googlefonts/colr-gradients-spec implies that Google could be considering switching from CBDT to COLR, suggesting the possibility that the CBDT format could become obsolete.

The NEWS file for Emacs 27.1 says:
“Multicolor fonts such as "Noto Color Emoji" can be displayed on
Emacs configured with Cairo drawing and linked with cairo >= 1.16.0.”
I would submit a patch to change this to mention that only CBDT is currently supported, but I’m not sure if that’s true on, e.g., Windows or MacOS.


In GNU Emacs 27.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.21, cairo version 1.16.0)
 of 2020-08-20 built on buildvm-x86-24.iad2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.12008000
System Description: Fedora 32 (Workstation Edition)

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER GMP

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

-- 
Peter Oliver

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

[Eli Zaretskii]

> From: Peter Oliver <lists.gnu.org@mavit.org.uk>
> Date: Wed, 26 Aug 2020 13:24:05 +0100
> 
> The NEWS file for Emacs 27.1 says:
> “Multicolor fonts such as "Noto Color Emoji" can be displayed on
> Emacs configured with Cairo drawing and linked with cairo >= 1.16.0.”
> I would submit a patch to change this to mention that only CBDT is currently supported, but I’m not sure if that’s true on, e.g., Windows or MacOS.

AFAIK, we support whatever Cairo supports, so stating the limitation
in our NEWS would be unwise, I think, because Cairo is also being
developed, and so such statements could become inaccurate outside of
our control.

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

[Peter Oliver]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Wed, 26 Aug 2020, Eli Zaretskii wrote:
^[OB
>> From: Peter Oliver <lists.gnu.org@mavit.org.uk>
>> Date: Wed, 26 Aug 2020 13:24:05 +0100
>>
>> The NEWS file for Emacs 27.1 says:
>> “Multicolor fonts such as "Noto Color Emoji" can be displayed on
>> Emacs configured with Cairo drawing and linked with cairo >= 1.16.0.”
>> I would submit a patch to change this to mention that only CBDT is currently supported, but I’m not sure if that’s true on, e.g., Windows or MacOS.
>
> AFAIK, we support whatever Cairo supports

As I say, COLR works in other GTK apps, so I don’t think it’s as simple as “Cairo doesn’t support that”.

Observation:

First I grabbed a COLR TTF (e.g., https://github.com/hfg-gmuend/openmoji/raw/47c9efe5449ba2ef77b77cdcae28b00811dea843/font/untouchedsvgz/OpenMoji-Color.ttf) and saved it to ~/.local/share/fonts/.  Then:

ELISP> (x-list-fonts "OpenMoji Color")
("-NONE-OpenMoji Color-normal-normal-normal-*-*-*-*-*-m-0-iso10646-1")
ELISP> (font-info (car (x-list-fonts "OpenMoji Color")))
nil

This makes me suspect that the problem isn’t with outputting with the font, but in finding the font in the first place.  I’m not sure how to go about debugging this.

-- 
Peter Oliver

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

[YAMAMOTO Mitsuharu]

On Thu, 27 Aug 2020 00:12:06 +0900,
Peter Oliver wrote:
> 
> Observation:
> 
> First I grabbed a COLR TTF (e.g., https://github.com/hfg-gmuend/openmoji/raw/47c9efe5449ba2ef77b77cdcae28b00811dea843/font/untouchedsvgz/OpenMoji-Color.ttf) and saved it to ~/.local/share/fonts/.  Then:
> 
> ELISP> (x-list-fonts "OpenMoji Color")
> ("-NONE-OpenMoji Color-normal-normal-normal-*-*-*-*-*-m-0-iso10646-1")
> ELISP> (font-info (car (x-list-fonts "OpenMoji Color")))
> nil
> 
> This makes me suspect that the problem isn’t with outputting with the font, but in finding the font in the first place.  I’m not sure how to go about debugging this.

The above font does not have the 'COLR' table, but the 'SVG ' one.  So
I think it is an SVG-in-OpenType font.

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

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

diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index e089f9dea8..9e83ad00d4 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -233,6 +233,7 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
   cairo_glyph_t stack_glyph;
   font->min_width = font->max_width = 0;
   font->average_width = font->space_width = 0;
+  int n = 0;
   for (char c = 32; c < 127; c++)
     {
       cairo_glyph_t *glyphs = &stack_glyph;
@@ -252,17 +253,20 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
 	  stack_glyph.index = 0;
 	}
       int this_width = ftcrfont_glyph_extents (font, stack_glyph.index, NULL);
-      if (this_width > 0
-	  && (! font->min_width
-	      || font->min_width > this_width))
-	font->min_width = this_width;
-      if (this_width > font->max_width)
-	font->max_width = this_width;
-      if (c == 32)
-	font->space_width = this_width;
-      font->average_width += this_width;
+      if (this_width > 0)
+	{
+	  if (! font->min_width || font->min_width > this_width)
+	    font->min_width = this_width;
+	  if (this_width > font->max_width)
+	    font->max_width = this_width;
+	  if (c == 32)
+	    font->space_width = this_width;
+	  font->average_width += this_width;
+	  n++;
+	}
     }
-  font->average_width /= 95;
+  if (n)
+    font->average_width /= n;
 
   cairo_scaled_font_extents (ftcrfont_info->cr_scaled_font, &extents);
   font->ascent = lround (extents.ascent);

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

[Eli Zaretskii]

> 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?  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.

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

[YAMAMOTO Mitsuharu]

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

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

[Eli Zaretskii]

> Date: Sun, 25 Sep 2022 15:40:59 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: lists.gnu.org@mavit.org.uk, 43058@debbugs.gnu.org
> 
> > 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.

OK, thanks.  I think on balance this means we should install this, so
please push to the master branch.

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

[YAMAMOTO Mitsuharu]

On Sun, 25 Sep 2022 17:03:22 +0900,
Eli Zaretskii wrote:
> 
> > 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.
> 
> OK, thanks.  I think on balance this means we should install this, so
> please push to the master branch.

Done.  According to Peter, the patch enables us to display some COLRv0
variant of OpenMoji Color font on Emacs.  (I also confirmed that with
cairo 1.17.4).  So closing the bug.

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

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

[Peter Oliver]

On Thu, 22 Sep 2022, YAMAMOTO Mitsuharu wrote:

> The above font does not have the 'COLR' table, but the 'SVG ' one.  So
> I think it is an SVG-in-OpenType font.

Apologies, I appear to have pasted the wrong URL previously.  The file that I intended to link to was https://github.com/mavit/openmoji/raw/nanoemoji/font/glyf_colr_0/OpenMoji-Color.COLRv0.ttf

> 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.

But it does allow the above COLR v0 font to be displayed here on Fedora 35.  Thank you.

-- 
Peter Oliver