unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
To: Peter Oliver <lists.gnu.org@mavit.org.uk>
Cc: 43058@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#43058: 27.1; Support for other colour font formats
Date: Thu, 22 Sep 2022 11:45:02 +0900	[thread overview]
Message-ID: <wl7d1wgma9.wl-mituharu@math.s.chiba-u.ac.jp> (raw)
In-Reply-To: <alpine.LFD.2.23.451.2008261510400.3319@froglet.home.mavit.org.uk>

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);





  reply	other threads:[~2022-09-22  2:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-26 12:24 bug#43058: 27.1; Support for other colour font formats Peter Oliver
2020-08-26 12:33 ` Eli Zaretskii
2020-08-26 15:12   ` Peter Oliver
2022-09-22  2:45     ` YAMAMOTO Mitsuharu [this message]
2022-09-22  7:10       ` Eli Zaretskii
2022-09-25  6:40         ` YAMAMOTO Mitsuharu
2022-09-25  8:03           ` Eli Zaretskii
2022-09-26  1:05             ` YAMAMOTO Mitsuharu
2022-09-25 22:47       ` Peter Oliver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wl7d1wgma9.wl-mituharu@math.s.chiba-u.ac.jp \
    --to=mituharu@math.s.chiba-u.ac.jp \
    --cc=43058@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=lists.gnu.org@mavit.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).