Status of multicolor fonts?

Status of multicolor fonts?

[Clément Pit--Claudel]

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

Hi emacs-devel,

Multicolor fonts seem to be becoming popular, especially for representing Emoji. There seems to be four competing standards to encode them (see http://blog.symbolset.com/multicolor-fonts for info and links). Both Apple and Microsoft distribute at least one such color Emoji font (Apple Color Emoji and Segoe UI Emoji). Google also has one, Noto Emoji, which is free as in beer and speech. Mozilla will release one soon, and so will the Emoji One project.

IIUC, Emacs on OSX can display at least some of these fonts properly. What is the status on other platforms? Is it dependent on the graphical toolkit with which Emacs is compiled?

For reference, here's a sample:

> 😀 😬 😁 😂 😃 😄 😅 😆 😇 😉 😊 🙂 🙃 ☺️ 😋 😌 😍 😘 😗 😙 😚 😜 😝
> 😛 🤑 🤓 😎 🤗 😏 😶 😐 😑 😒 🙄 🤔 😳 😞 😟 😠 😡 😔 😕 🙁 ☹️ 😣 😖
> 😫 😩 😤 😮 😱 😨 😰 😯 😦 😧 😢 😥 😪 😓 😭 😵 😲 🤐 😷 🤒 🤕 😴

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Wed, 16 Dec 2015 08:40:24 -0500
> 
> Multicolor fonts seem to be becoming popular, especially for representing Emoji. There seems to be four competing standards to encode them (see http://blog.symbolset.com/multicolor-fonts for info and links). Both Apple and Microsoft distribute at least one such color Emoji font (Apple Color Emoji and Segoe UI Emoji). Google also has one, Noto Emoji, which is free as in beer and speech. Mozilla will release one soon, and so will the Emoji One project.
> 
> IIUC, Emacs on OSX can display at least some of these fonts properly. What is the status on other platforms? Is it dependent on the graphical toolkit with which Emacs is compiled?

What do you mean by "display these fonts properly"?  The characters
will be displayed on any platform, in their text representation, but
AFAIK Emacs doesn't take color information from the font; the color is
determined by the color attributes of the face.  We also don't support
emoji modifiers and emoji variation selectors.

Really, for keeping up with these developments, we'd need to recruit
at least one person who is expert in this area, and can develop Emacs
capabilities related to latest versions of the Unicode standard.  We
don't have such a person on board at this time.

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 09:10 AM, Eli Zaretskii wrote:
>> From: Clément Pit--Claudel <clement.pit@gmail.com> Date: Wed, 16
>> Dec 2015 08:40:24 -0500
>> 
>> Multicolor fonts seem to be becoming popular, especially for
>> representing Emoji. There seems to be four competing standards to
>> encode them (see http://blog.symbolset.com/multicolor-fonts for
>> info and links). Both Apple and Microsoft distribute at least one
>> such color Emoji font (Apple Color Emoji and Segoe UI Emoji).
>> Google also has one, Noto Emoji, which is free as in beer and
>> speech. Mozilla will release one soon, and so will the Emoji One
>> project.
>> 
>> IIUC, Emacs on OSX can display at least some of these fonts
>> properly. What is the status on other platforms? Is it dependent on
>> the graphical toolkit with which Emacs is compiled?
> 
> What do you mean by "display these fonts properly"?  The characters 
> will be displayed on any platform, in their text representation, but 
> AFAIK Emacs doesn't take color information from the font; the color
> is determined by the color attributes of the face.  We also don't
> support emoji modifiers and emoji variation selectors.

I meant display them in full color. I believe the MacOS build of Emacs already does this, but feedback from a MacOS user would be welcome. Is seems that on that platform setting the font to Apple Color Emoji is enough to get emjis to render in full color (see for example this screenshot: https://cloud.githubusercontent.com/assets/145117/10459946/14bcf9c8-71a0-11e5-881c-757878b706a5.png). 

Maybe David (cc'ed) can provide insight?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 09:10 AM, Eli Zaretskii wrote:
> The characters
> will be displayed on any platform, in their text representation, but
> AFAIK Emacs doesn't take color information from the font; the color is
> determined by the color attributes of the face.  We also don't support
> emoji modifiers and emoji variation selectors.

Looking at the code in more detail suggests that it in fact does on Mac, in macfont.m. The relevant bits of code were merged from Macport by Jab Djärv in May of 2014:

    macfont_info->color_bitmap_p = 0;
    if (sym_traits & kCTFontTraitColorGlyphs)
      macfont_info->color_bitmap_p = 1;

and further below

    #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
          if (macfont_info->color_bitmap_p
    #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
              && CTFontDrawGlyphs != NULL
    #endif
              )
            {
              if (len > 0)
                {
                  CTFontDrawGlyphs (macfont_info->macfont, glyphs, positions, len,
                                    context);
                }
            }
          else
    #endif	/* MAC_OS_X_VERSION_MAX_ALLOWED >= 1070 */
            {
              CGContextSetFont (context, macfont_info->cgfont);
              CGContextSetFontSize (context, font_size);
              CGContextShowGlyphsAtPositions (context, glyphs, positions, len);
            }
        }

This seems to be using Apple-specific APIs, however, so it probably does not help much for other platforms. Still, it would be nice to have similar features on GNU/Linux. The patches that allowed this to function on MacOS were small; I wonder if it would be the same on other platforms. 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Yuri Khan]

On Thu, Dec 17, 2015 at 4:20 AM, Clément Pit--Claudel
<clement.pit@gmail.com> wrote:
> This seems to be using Apple-specific APIs, however, so it probably does not help much for other platforms. Still, it would be nice to have similar features on GNU/Linux. The patches that allowed this to function on MacOS were small; I wonder if it would be the same on other platforms.

If you want it on X11/GNU/Linux, you better start by convincing
FreeType developers and/or sending them a patch. I sure don’t want
each application implementing color fonts separately — if they get
implemented at all, I want to be able to disable them everywhere with
just one user setting.

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 09:47 PM, Yuri Khan wrote:
> On Thu, Dec 17, 2015 at 4:20 AM, Clément Pit--Claudel 
> <clement.pit@gmail.com> wrote:
>> This seems to be using Apple-specific APIs, however, so it probably
>> does not help much for other platforms. Still, it would be nice to
>> have similar features on GNU/Linux. The patches that allowed this
>> to function on MacOS were small; I wonder if it would be the same
>> on other platforms.
> 
> If you want it on X11/GNU/Linux, you better start by convincing 
> FreeType developers and/or sending them a patch. I sure don’t want 
> each application implementing color fonts separately — if they get 
> implemented at all, I want to be able to disable them everywhere
> with just one user setting.

Fortunately, support for this was added in Freetype in 2013, so I won't have much convincing to do, nor much patch-sending. It's also implemented in FontConfig. Plenty of applications compiled for GNU/Linux support it out of the box too, such as Mozilla Firefox and Chrome Linux.
As for disabling it, it's pretty easy: just don't enable it :) That is, just don't install a multicolor font.

Cheers,
Clément.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Wed, 16 Dec 2015 22:14:14 -0500
> Cc: Eli Zaretskii <eliz@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> >> This seems to be using Apple-specific APIs, however, so it probably
> >> does not help much for other platforms. Still, it would be nice to
> >> have similar features on GNU/Linux. The patches that allowed this
> >> to function on MacOS were small; I wonder if it would be the same
> >> on other platforms.
> > 
> > If you want it on X11/GNU/Linux, you better start by convincing 
> > FreeType developers and/or sending them a patch. I sure don’t want 
> > each application implementing color fonts separately — if they get 
> > implemented at all, I want to be able to disable them everywhere
> > with just one user setting.
> 
> Fortunately, support for this was added in Freetype in 2013, so I won't have much convincing to do, nor much patch-sending. It's also implemented in FontConfig. Plenty of applications compiled for GNU/Linux support it out of the box too, such as Mozilla Firefox and Chrome Linux.

Patches are welcome to add support for this to Emacs on Posix systems.
On MS-Windows, this would require to switch from Uniscribe to
DirectWrite, AFAIU, which presents only C++ APIs, so it would be
harder.

Re: Status of multicolor fonts?

[Rüdiger Sonderfeld]

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

On Wednesday 16 December 2015 22:14:14 Clément Pit--Claudel wrote:
> Fortunately, support for this was added in Freetype in 2013, so I won't have
> much convincing to do, nor much patch-sending. It's also implemented in
> FontConfig. Plenty of applications compiled for GNU/Linux support it out of
> the box too, such as Mozilla Firefox and Chrome Linux. As for disabling it,
> it's pretty easy: just don't enable it :) That is, just don't install a
> multicolor font.

LibXft does not seem to have support for multicolor fonts though.  There is a 
patch to add initial support:

http://lists.x.org/archives/xorg-devel/2015-August/047175.html

But it seems this hasn't been merged and I'm not sure if this is actively 
developed.  If this patch (or something similar) gets merged then it seems 
enabling it in GNU Emacs will be as simple as setting the FC_COLOR value for 
fontconfig in xftfont.c.

Cheers,

Rüdiger

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 16 Dec 2015 17:20:52 -0500, Cl9ment Pit--Claudel <clement.pit@gmail.com> said:

>> The characters will be displayed on any platform, in their text
>> representation, but AFAIK Emacs doesn't take color information from
>> the font; the color is determined by the color attributes of the
>> face.  We also don't support emoji modifiers and emoji variation
>> selectors.

> Looking at the code in more detail suggests that it in fact does on
> Mac, in macfont.m. The relevant bits of code were merged from
> Macport by Jab Djärv in May of 2014:

>     macfont_info-> color_bitmap_p = 0;
>     if (sym_traits & kCTFontTraitColorGlyphs)
>     macfont_info-> color_bitmap_p = 1;

> and further below

>     #if MAC_OS_X_VERSION_MAX_ALLOWED >= 1070
>           if (macfont_info->color_bitmap_p
>     #if MAC_OS_X_VERSION_MIN_REQUIRED < 1070
>               && CTFontDrawGlyphs != NULL
>     #endif
>               )
>             {
>               if (len > 0)
>                 {
>                   CTFontDrawGlyphs (macfont_info->macfont, glyphs, positions, len,
>                                     context);
>                 }
>             }
>           else
>     #endif	/* MAC_OS_X_VERSION_MAX_ALLOWED >= 1070 */
>             {
>               CGContextSetFont (context, macfont_info->cgfont);
>               CGContextSetFontSize (context, font_size);
>               CGContextShowGlyphsAtPositions (context, glyphs, positions, len);
>             }
>         }

> This seems to be using Apple-specific APIs, however, so it probably
> does not help much for other platforms. Still, it would be nice to
> have similar features on GNU/Linux. The patches that allowed this to
> function on MacOS were small; I wonder if it would be the same on
> other platforms.

According to the discussion about the inclusion of the Mac port, it
seems that this code should be removed from the mainline if we require
multicolor font implementations on free platforms first.  WDYT?

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

Re: Status of multicolor fonts?

[John Wiegley]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>> This seems to be using Apple-specific APIs, however, so it probably does
>> not help much for other platforms. Still, it would be nice to have similar
>> features on GNU/Linux. The patches that allowed this to function on MacOS
>> were small; I wonder if it would be the same on other platforms.

> According to the discussion about the inclusion of the Mac port, it seems
> that this code should be removed from the mainline if we require multicolor
> font implementations on free platforms first. WDYT?

Touché, and point to Yamamoto-san. Richard?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Status of multicolor fonts?

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 05 Jan 2016 22:23:15 -0800, John Wiegley <jwiegley@gmail.com> said:

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>>> This seems to be using Apple-specific APIs, however, so it
>>> probably does not help much for other platforms. Still, it would
>>> be nice to have similar features on GNU/Linux. The patches that
>>> allowed this to function on MacOS were small; I wonder if it would
>>> be the same on other platforms.

>> According to the discussion about the inclusion of the Mac port, it
>> seems that this code should be removed from the mainline if we
>> require multicolor font implementations on free platforms
>> first. WDYT?

> Touché, and point to Yamamoto-san. Richard?

Ping?  If there is no plan to support multicolor fonts in Emacs 25.1
on free platforms, then I'll disable them on the mac-ct font backend
driver.

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

Re: Status of multicolor fonts?

[John Wiegley]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Ping? If there is no plan to support multicolor fonts in Emacs 25.1 on free
> platforms, then I'll disable them on the mac-ct font backend driver.

I wouldn't say there are no plans, or that we wouldn't want it, it's just not
very high up on the priority list. If some volunteer wants to take it on, then
we could enable it in your code.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Status of multicolor fonts?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 11 Apr 2016 16:19:24 -0700, John Wiegley <jwiegley@gmail.com> said:

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> Ping? If there is no plan to support multicolor fonts in Emacs 25.1
>> on free platforms, then I'll disable them on the mac-ct font
>> backend driver.

> I wouldn't say there are no plans, or that we wouldn't want it, it's
> just not very high up on the priority list. If some volunteer wants
> to take it on, then we could enable it in your code.

I've just disabled it.  Let's re-enable it when the above happens.

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

Re: Status of multicolor fonts?

[YAMAMOTO Mitsuharu]

On Tue, 12 Apr 2016 08:34:47 +0900,
YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> wrote:
> 
> >>>>> On Mon, 11 Apr 2016 16:19:24 -0700, John Wiegley <jwiegley@gmail.com> said:
> 
> >>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
> >> Ping? If there is no plan to support multicolor fonts in Emacs 25.1
> >> on free platforms, then I'll disable them on the mac-ct font
> >> backend driver.
> 
> > I wouldn't say there are no plans, or that we wouldn't want it, it's
> > just not very high up on the priority list. If some volunteer wants
> > to take it on, then we could enable it in your code.
> 
> I've just disabled it.  Let's re-enable it when the above happens.

Now the cairo build on master can display multicolor font if linked
with cairo >= 1.16.0.

  (set-fontset-font t #x1f600 (font-spec :family "Noto Color Emoji"))
  (insert #x1f600)

Does it count as multicolor font support on free platforms?

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

Re: Status of multicolor fonts?

[Eli Zaretskii]

> Date: Wed, 24 Apr 2019 12:45:05 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> 
> > I've just disabled it.  Let's re-enable it when the above happens.
> 
> Now the cairo build on master can display multicolor font if linked
> with cairo >= 1.16.0.
> 
>   (set-fontset-font t #x1f600 (font-spec :family "Noto Color Emoji"))
>   (insert #x1f600)

I think this should be mentioned in the manual and in NEWS.

> Does it count as multicolor font support on free platforms?

I think it does, yes.  Thanks for working on this.

As long as I have your attention: could you please help in finishing
the development of the harfbuzz branch and landing it on master?  For
Posix platforms, there are just a few finishing touches left, I think,
the main one being make a separate font backend that uses HarfBuzz
interfaces for as many backend facilities as possible (I will tell the
details if you can offer help).  I'd appreciate help in this area.
TIA.

Re: Status of multicolor fonts?

[mituharu]

>> Date: Wed, 24 Apr 2019 12:45:05 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>>
>> > I've just disabled it.  Let's re-enable it when the above happens.
>>
>> Now the cairo build on master can display multicolor font if linked
>> with cairo >= 1.16.0.
>>
>>   (set-fontset-font t #x1f600 (font-spec :family "Noto Color Emoji"))
>>   (insert #x1f600)
>
> I think this should be mentioned in the manual and in NEWS.
>
>> Does it count as multicolor font support on free platforms?
>
> I think it does, yes.  Thanks for working on this.

I've added some NEWS entries, and re-enabled multicolor fonts
for the mac-ct font backend driver.

> As long as I have your attention: could you please help in finishing
> the development of the harfbuzz branch and landing it on master?  For
> Posix platforms, there are just a few finishing touches left, I think,
> the main one being make a separate font backend that uses HarfBuzz
> interfaces for as many backend facilities as possible (I will tell the
> details if you can offer help).  I'd appreciate help in this area.
> TIA.

I don't know if I'll be of any help, but could you explain the details?
Is it OK to merge master to the harfbuzz branch as the first step
so as to resolve some conflicts caused by my recent commits?

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

Re: Status of multicolor fonts?

[Eli Zaretskii]

> Date: Sat, 27 Apr 2019 17:13:24 +0900
> From: mituharu@math.s.chiba-u.ac.jp
> Cc: emacs-devel@gnu.org
> 
> >> Does it count as multicolor font support on free platforms?
> >
> > I think it does, yes.  Thanks for working on this.
> 
> I've added some NEWS entries, and re-enabled multicolor fonts
> for the mac-ct font backend driver.

Thanks.

> > As long as I have your attention: could you please help in finishing
> > the development of the harfbuzz branch and landing it on master?  For
> > Posix platforms, there are just a few finishing touches left, I think,
> > the main one being make a separate font backend that uses HarfBuzz
> > interfaces for as many backend facilities as possible (I will tell the
> > details if you can offer help).  I'd appreciate help in this area.
> > TIA.
> 
> I don't know if I'll be of any help, but could you explain the details?

I think I can, but please ask more specific questions.

The general idea is to use HarfBuzz as a font backend which supports
layout of complex scripts, as a replacement for libm17n-flt on
GNU/Linux and as a replacement for Uniscribe on MS-Windows.  The
current code on the branch uses compile-time CPP directives to select
HarfBuzz as the shaper for xftfont and other font back-ends, but I
would like to make it a separate font backend instead, so that people
could choose which one to use.  I also think not every existing font
backend needs to be able to use HarfBuzz, only those which support OTF
and TTF font features should.

> Is it OK to merge master to the harfbuzz branch as the first step
> so as to resolve some conflicts caused by my recent commits?

Yes, please.  In fact, seeing your Cairo changes was what prompted me
to ask you for help in the first place.  The HarfBuzz people wrote the
initial code of the branch, but they said some time ago they didn't
have enough time to work on this, although they will answer questions
regarding HarfBuzz functionality (there's a mailing list dedicate to
HarfBuzz development and use).

TIA

landing harfbuzz branch (Re: Status of multicolor fonts?)

[mituharu]

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

> The general idea is to use HarfBuzz as a font backend which supports
> layout of complex scripts, as a replacement for libm17n-flt on
> GNU/Linux and as a replacement for Uniscribe on MS-Windows.  The
> current code on the branch uses compile-time CPP directives to select
> HarfBuzz as the shaper for xftfont and other font back-ends, but I
> would like to make it a separate font backend instead, so that people
> could choose which one to use.  I also think not every existing font
> backend needs to be able to use HarfBuzz, only those which support OTF
> and TTF font features should.

The attached patch is against the harfbuzz branch, and it adds
`xfthb' and `ftcrhb' backends that use HarfBuzz for shaping.  I
also tried adding the `mac-cthb' backend, but it is not included
in the patch.

With the `ftcrhb' font backend, one can now display regional flag
emojis:

(make-frame '((font-backend ftcrhb)))
(set-fontset-font t '(#x1F1E6 . #x1F1FF) (font-spec :family "Noto Color
Emoji"))
(set-char-table-range composition-function-table '(#x1F1E6 . #x1F1FF)
		      '([".[\x1F1E6-\x1F1FF]" 0 font-shape-gstring]))
(insert (+ ?j (- #x1F1E6 ?a)) (+ ?p (- #x1F1E6 ?a)))

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

[-- Attachment #2: hb-font-backends.diff --]
[-- Type: application/octet-stream, Size: 24093 bytes --]

diff --git a/src/font.h b/src/font.h
index 3540a8dba22..1f62a61f0be 100644
--- a/src/font.h
+++ b/src/font.h
@@ -22,6 +22,10 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #ifndef EMACS_FONT_H
 #define EMACS_FONT_H
 
+#ifdef HAVE_HARFBUZZ
+#include <hb.h>
+#endif	/* HAVE_HARFBUZZ */
+
 struct composition_it;
 struct face;
 struct glyph_string;
@@ -780,6 +784,21 @@ struct font_driver
      relies on this hook to throw away its old XftDraw (which won't
      work after the size change) and get a new one.  */
   void (*drop_xrender_surfaces) (struct frame *f);
+
+#ifdef HAVE_HARFBUZZ
+  /* Optional.
+     Return a HarfBuzz font object for FONT and store to
+     *POSITION_UNIT the scale factor to convert a hb_position_t value
+     to the number of pixels.  Return NULL if HarfBuzz font object is
+     not available for FONT.  */
+  hb_font_t *(*begin_hb_font) (struct font *font, double *position_unit);
+
+  /* Optional.
+     Called when the return value (passed as HB_FONT) of begin_hb_font
+     above is no longer used.  Not called if the return value of
+     begin_hb_font was NULL.  */
+  void (*end_hb_font) (struct font *font, hb_font_t *hb_font);
+#endif	/* HAVE_HARFBUZZ */
 };
 
 
@@ -892,9 +911,9 @@ extern int ftfont_has_char (Lisp_Object, int);
 extern int ftfont_variation_glyphs (struct font *, int, unsigned[256]);
 extern Lisp_Object ftfont_combining_capability (struct font *);
 extern Lisp_Object ftfont_get_cache (struct frame *);
-extern Lisp_Object ftfont_list (struct frame *, Lisp_Object);
+extern Lisp_Object ftfont_list2 (struct frame *, Lisp_Object, Lisp_Object);
 extern Lisp_Object ftfont_list_family (struct frame *);
-extern Lisp_Object ftfont_match (struct frame *, Lisp_Object);
+extern Lisp_Object ftfont_match2 (struct frame *, Lisp_Object, Lisp_Object);
 extern Lisp_Object ftfont_open (struct frame *, Lisp_Object, int);
 extern Lisp_Object ftfont_otf_capability (struct font *);
 extern Lisp_Object ftfont_shape (Lisp_Object, Lisp_Object);
@@ -903,6 +922,11 @@ extern void ftfont_close (struct font *);
 extern void ftfont_filter_properties (Lisp_Object, Lisp_Object);
 extern void ftfont_text_extents (struct font *, unsigned *, int,
 				 struct font_metrics *);
+#ifdef HAVE_HARFBUZZ
+extern Lisp_Object fthbfont_combining_capability (struct font *);
+extern hb_font_t *fthbfont_begin_hb_font (struct font *, double *);
+extern Lisp_Object fthbfont_shape (Lisp_Object, Lisp_Object);
+#endif	/* HAVE_HARFBUZZ */
 extern void syms_of_ftfont (void);
 #endif	/* HAVE_FREETYPE */
 #ifdef HAVE_X_WINDOWS
@@ -912,6 +936,9 @@ extern void syms_of_xfont (void);
 extern void syms_of_ftxfont (void);
 #ifdef HAVE_XFT
 extern struct font_driver const xftfont_driver;
+#ifdef HAVE_HARFBUZZ
+extern struct font_driver xfthbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 #endif
 #if defined HAVE_FREETYPE || defined HAVE_XFT
 extern struct font_driver const ftxfont_driver;
@@ -933,6 +960,9 @@ extern void syms_of_macfont (void);
 #endif	/* HAVE_NS */
 #ifdef USE_CAIRO
 extern struct font_driver const ftcrfont_driver;
+#ifdef HAVE_HARFBUZZ
+extern struct font_driver ftcrhbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 extern void syms_of_ftcrfont (void);
 #endif
 
diff --git a/src/ftcrfont.c b/src/ftcrfont.c
index c0f62e0418e..dc59c2bcadc 100644
--- a/src/ftcrfont.c
+++ b/src/ftcrfont.c
@@ -98,21 +98,13 @@ ftcrfont_glyph_extents (struct font *font,
 static Lisp_Object
 ftcrfont_list (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object list = ftfont_list (f, spec), tail;
-
-  for (tail = list; CONSP (tail); tail = XCDR (tail))
-    ASET (XCAR (tail), FONT_TYPE_INDEX, Qftcr);
-  return list;
+  return ftfont_list2 (f, spec, Qftcr);
 }
 
 static Lisp_Object
 ftcrfont_match (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object entity = ftfont_match (f, spec);
-
-  if (VECTORP (entity))
-    ASET (entity, FONT_TYPE_INDEX, Qftcr);
-  return entity;
+  return ftfont_match2 (f, spec, Qftcr);
 }
 
 static Lisp_Object
@@ -124,7 +116,8 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
   if (size == 0)
     size = pixel_size;
   font_object = font_build_object (VECSIZE (struct font_info),
-				   Qftcr, entity, size);
+				   AREF (entity, FONT_TYPE_INDEX),
+				   entity, size);
   block_input ();
   font_object = ftfont_open2 (f, entity, pixel_size, font_object);
   if (FONT_OBJECT_P (font_object))
@@ -133,6 +126,11 @@ ftcrfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
       struct font_info *ftcrfont_info = (struct font_info *) font;
       FT_Face ft_face = ftcrfont_info->ft_size->face;
 
+#ifdef HAVE_HARFBUZZ
+      if (EQ (AREF (font_object, FONT_TYPE_INDEX), Qftcrhb))
+	font->driver = &ftcrhbfont_driver;
+      else
+#endif	/* HAVE_HARFBUZZ */
       font->driver = &ftcrfont_driver;
       FT_New_Size (ft_face, &ftcrfont_info->ft_size_draw);
       FT_Activate_Size (ftcrfont_info->ft_size_draw);
@@ -291,7 +289,7 @@ ftcrfont_anchor_point (struct font *font, unsigned int code, int idx,
 static Lisp_Object
 ftcrfont_shape (Lisp_Object lgstring, Lisp_Object direction)
 {
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
   struct font *font = CHECK_FONT_GET_OBJECT (LGSTRING_FONT (lgstring));
   struct font_info *ftcrfont_info = (struct font_info *) font;
 
@@ -361,6 +359,39 @@ ftcrfont_draw (struct glyph_string *s,
   return len;
 }
 
+#ifdef HAVE_HARFBUZZ
+
+static Lisp_Object
+ftcrhbfont_list (struct frame *f, Lisp_Object spec)
+{
+  return ftfont_list2 (f, spec, Qftcrhb);
+}
+
+static Lisp_Object
+ftcrhbfont_match (struct frame *f, Lisp_Object spec)
+{
+  return ftfont_match2 (f, spec, Qftcrhb);
+}
+
+static hb_font_t *
+ftcrhbfont_begin_hb_font (struct font *font, double *position_unit)
+{
+  struct font_info *ftcrfont_info = (struct font_info *) font;
+
+  FT_Activate_Size (ftcrfont_info->ft_size_draw);
+  hb_font_t *hb_font = fthbfont_begin_hb_font (font, position_unit);
+  int i = ftcrfont_info->bitmap_strike_index;
+  if (i >= 0)
+    {
+      FT_Face ft_face = ftcrfont_info->ft_size_draw->face;
+      *position_unit = ((double) font->height
+			/ ft_face->available_sizes[i].height) / (1 << 6);
+    }
+
+  return hb_font;
+}
+
+#endif	/* HAVE_HARFBUZZ */
 \f
 
 static void syms_of_ftcrfont_for_pdumper (void);
@@ -390,11 +421,17 @@ struct font_driver const ftcrfont_driver =
   .filter_properties = ftfont_filter_properties,
   .combining_capability = ftfont_combining_capability,
   };
+#ifdef HAVE_HARFBUZZ
+struct font_driver ftcrhbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 
 void
 syms_of_ftcrfont (void)
 {
   DEFSYM (Qftcr, "ftcr");
+#ifdef HAVE_HARFBUZZ
+  DEFSYM (Qftcrhb, "ftcrhb");
+#endif	/* HAVE_HARFBUZZ */
   pdumper_do_now_and_after_load (syms_of_ftcrfont_for_pdumper);
 }
 
@@ -402,4 +439,14 @@ static void
 syms_of_ftcrfont_for_pdumper (void)
 {
   register_font_driver (&ftcrfont_driver, NULL);
+#ifdef HAVE_HARFBUZZ
+  ftcrhbfont_driver = ftcrfont_driver;
+  ftcrhbfont_driver.type = Qftcrhb;
+  ftcrhbfont_driver.list = ftcrhbfont_list;
+  ftcrhbfont_driver.match = ftcrhbfont_match;
+  ftcrhbfont_driver.shape = fthbfont_shape;
+  ftcrhbfont_driver.combining_capability = fthbfont_combining_capability;
+  ftcrhbfont_driver.begin_hb_font = ftcrhbfont_begin_hb_font;
+  register_font_driver (&ftcrhbfont_driver, NULL);
+#endif	/* HAVE_HARFBUZZ */
 }
diff --git a/src/ftfont.c b/src/ftfont.c
index 58c462a90fe..718fae2b87b 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -21,6 +21,7 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
 #include <config.h>
 #include <stdio.h>
+#include <math.h>
 #include <fontconfig/fontconfig.h>
 #include <fontconfig/fcfreetype.h>
 
@@ -48,6 +49,9 @@ along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 #include "pdumper.h"
 
 static struct font_driver const ftfont_driver;
+#ifdef HAVE_HARFBUZZ
+static struct font_driver fthbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 
 /* Flag to tell if FcInit is already called or not.  */
 static bool fc_initialized;
@@ -466,19 +470,6 @@ ftfont_get_otf (struct font_info *ftfont_info)
 }
 #endif	/* HAVE_LIBOTF */
 
-#ifdef HAVE_HARFBUZZ
-
-static hb_font_t *
-ftfont_get_hb_font (struct font_info *ftfont_info)
-{
-  if (! ftfont_info->hb_font)
-    ftfont_info->hb_font
-      = hb_ft_font_create_referenced (ftfont_info->ft_size->face);
-  return ftfont_info->hb_font;
-}
-
-#endif	/* HAVE_HARFBUZZ */
-
 Lisp_Object
 ftfont_get_cache (struct frame *f)
 {
@@ -801,7 +792,7 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
   return pattern;
 }
 
-Lisp_Object
+static Lisp_Object
 ftfont_list (struct frame *f, Lisp_Object spec)
 {
   Lisp_Object val = Qnil, family, adstyle;
@@ -1001,6 +992,16 @@ ftfont_list (struct frame *f, Lisp_Object spec)
 }
 
 Lisp_Object
+ftfont_list2 (struct frame *f, Lisp_Object spec, Lisp_Object type)
+{
+  Lisp_Object list = ftfont_list (f, spec);
+
+  for (Lisp_Object tail = list; CONSP (tail); tail = XCDR (tail))
+    ASET (XCAR (tail), FONT_TYPE_INDEX, type);
+  return list;
+}
+
+static Lisp_Object
 ftfont_match (struct frame *f, Lisp_Object spec)
 {
   Lisp_Object entity = Qnil;
@@ -1050,6 +1051,16 @@ ftfont_match (struct frame *f, Lisp_Object spec)
   return entity;
 }
 
+Lisp_Object
+ftfont_match2 (struct frame *f, Lisp_Object spec, Lisp_Object type)
+{
+  Lisp_Object entity = ftfont_match (f, spec);
+
+  if (! NILP (entity))
+    ASET (entity, FONT_TYPE_INDEX, type);
+  return entity;
+}
+
 Lisp_Object
 ftfont_list_family (struct frame *f)
 {
@@ -1185,6 +1196,11 @@ ftfont_open2 (struct frame *f,
   /* This means that there's no need of transformation.  */
   ftfont_info->matrix.xx = 0;
   font->pixel_size = size;
+#ifdef HAVE_HARFBUZZ
+  if (EQ (AREF (font_object, FONT_TYPE_INDEX), Qfreetypehb))
+    font->driver = &fthbfont_driver;
+  else
+#endif	/* HAVE_HARFBUZZ */
   font->driver = &ftfont_driver;
   font->encoding_charset = font->repertory_charset = -1;
 
@@ -1266,7 +1282,8 @@ ftfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
   if (size == 0)
     size = pixel_size;
   font_object = font_build_object (VECSIZE (struct font_info),
-				   Qfreetype, entity, size);
+				   AREF (entity, FONT_TYPE_INDEX),
+				   entity, size);
   font_object = ftfont_open2 (f, entity, pixel_size, font_object);
   if (FONT_OBJECT_P (font_object))
     {
@@ -2673,6 +2690,17 @@ ftfont_shape_by_flt (Lisp_Object lgstring, struct font *font,
   return make_fixnum (i);
 }
 
+Lisp_Object
+ftfont_shape (Lisp_Object lgstring)
+{
+  struct font *font = CHECK_FONT_GET_OBJECT (LGSTRING_FONT (lgstring));
+  struct font_info *ftfont_info = (struct font_info *) font;
+  OTF *otf = ftfont_get_otf (ftfont_info);
+
+  return ftfont_shape_by_flt (lgstring, font, ftfont_info->ft_size->face, otf,
+			      &ftfont_info->matrix);
+}
+
 #endif	/* HAVE_M17N_FLT */
 
 #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
@@ -2693,6 +2721,18 @@ ftfont_variation_glyphs (struct font *font, int c, unsigned variations[256])
 
 #ifdef HAVE_HARFBUZZ
 
+hb_font_t *
+fthbfont_begin_hb_font (struct font *font, double *position_unit)
+{
+  struct font_info *ftfont_info = (struct font_info *) font;
+
+  *position_unit = 1.0 / (1 << 6);
+  if (! ftfont_info->hb_font)
+    ftfont_info->hb_font
+      = hb_ft_font_create_referenced (ftfont_info->ft_size->face);
+  return ftfont_info->hb_font;
+}
+
 static hb_unicode_combining_class_t
 uni_combining (hb_unicode_funcs_t *funcs, hb_codepoint_t ch, void *user_data)
 {
@@ -2818,8 +2858,8 @@ get_hb_unicode_funcs (void)
 }
 
 static Lisp_Object
-ftfont_shape_by_hb (Lisp_Object lgstring, FT_Face ft_face, hb_font_t *hb_font,
-                    FT_Matrix *matrix, Lisp_Object direction)
+ftfont_shape_by_hb (Lisp_Object lgstring, struct font *font,
+		    Lisp_Object direction)
 {
   ptrdiff_t glyph_len = 0, text_len = LGSTRING_GLYPH_LEN (lgstring);
   ptrdiff_t i;
@@ -2892,7 +2932,15 @@ ftfont_shape_by_hb (Lisp_Object lgstring, FT_Face ft_face, hb_font_t *hb_font,
      above. FIXME: drop once script handling is fixed above. */
   hb_buffer_guess_segment_properties (hb_buffer);
 
-  if (!hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL))
+  double position_unit;
+  hb_font_t *hb_font = font->driver->begin_hb_font (font, &position_unit);
+  if (!hb_font)
+    return make_fixnum (0);
+
+  hb_bool_t success = hb_shape_full (hb_font, hb_buffer, NULL, 0, NULL);
+  if (font->driver->end_hb_font)
+    font->driver->end_hb_font (font, hb_font);
+  if (!success)
     return Qnil;
 
   glyph_len = hb_buffer_get_length (hb_buffer);
@@ -2913,7 +2961,8 @@ ftfont_shape_by_hb (Lisp_Object lgstring, FT_Face ft_face, hb_font_t *hb_font,
     {
       Lisp_Object lglyph = LGSTRING_GLYPH (lgstring, i);
       EMACS_INT from, to;
-      int advance = 0, lbearing, rbearing, ascent, descent;
+      struct font_metrics metrics = {.width = 0};
+      int xoff, yoff, wadjust;
       ptrdiff_t j = i;
 
       if (NILP (lglyph))
@@ -2936,61 +2985,46 @@ ftfont_shape_by_hb (Lisp_Object lgstring, FT_Face ft_face, hb_font_t *hb_font,
       LGLYPH_SET_CHAR (lglyph, LGLYPH_CHAR (LGSTRING_GLYPH (lgstring, from)));
       LGLYPH_SET_CODE (lglyph, info[i].codepoint);
 
-      if (ftfont_glyph_metrics (ft_face, info[i].codepoint, &advance, &lbearing,
-                                &rbearing, &ascent, &descent))
-        {
-          LGLYPH_SET_WIDTH (lglyph, advance);
-          LGLYPH_SET_LBEARING (lglyph, lbearing);
-          LGLYPH_SET_RBEARING (lglyph, rbearing);
-          LGLYPH_SET_ASCENT (lglyph, ascent);
-          LGLYPH_SET_DESCENT (lglyph, descent);
-        }
-
-      if (pos[i].x_offset || pos[i].y_offset ||
-          (pos[i].x_advance >> 6) != advance)
-      {
-        Lisp_Object vec = make_uninit_vector (3);
-        ASET (vec, 0, make_fixnum (pos[i].x_offset >> 6));
-        ASET (vec, 1, make_fixnum (-(pos[i].y_offset >> 6)));
-        ASET (vec, 2, make_fixnum (pos[i].x_advance >> 6));
-        LGLYPH_SET_ADJUSTMENT (lglyph, vec);
-      }
+      unsigned code = info[i].codepoint;
+      font->driver->text_extents (font, &code, 1, &metrics);
+      LGLYPH_SET_WIDTH (lglyph, metrics.width);
+      LGLYPH_SET_LBEARING (lglyph, metrics.lbearing);
+      LGLYPH_SET_RBEARING (lglyph, metrics.rbearing);
+      LGLYPH_SET_ASCENT (lglyph, metrics.ascent);
+      LGLYPH_SET_DESCENT (lglyph, metrics.descent);
+
+      xoff = lround (pos[i].x_offset * position_unit);
+      yoff = - lround (pos[i].y_offset * position_unit);
+      wadjust = lround (pos[i].x_advance * position_unit);
+      if (xoff || yoff || wadjust != metrics.width)
+	{
+	  Lisp_Object vec = make_uninit_vector (3);
+	  ASET (vec, 0, make_fixnum (xoff));
+	  ASET (vec, 1, make_fixnum (yoff));
+	  ASET (vec, 2, make_fixnum (wadjust));
+	  LGLYPH_SET_ADJUSTMENT (lglyph, vec);
+	}
     }
 
   return make_fixnum (glyph_len);
 }
 
-#endif /* HAVE_HARFBUZZ */
-
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+Lisp_Object
+fthbfont_combining_capability (struct font *font)
+{
+  return Qt;
+}
 
 Lisp_Object
-ftfont_shape (Lisp_Object lgstring, Lisp_Object direction)
+fthbfont_shape (Lisp_Object lgstring, Lisp_Object direction)
 {
   struct font *font = CHECK_FONT_GET_OBJECT (LGSTRING_FONT (lgstring));
   struct font_info *ftfont_info = (struct font_info *) font;
-#ifdef HAVE_HARFBUZZ
-  if (getenv ("EMACS_NO_HARFBUZZ") == NULL)
-    {
-      hb_font_t *hb_font = ftfont_get_hb_font (ftfont_info);
-
-      return ftfont_shape_by_hb (lgstring, ftfont_info->ft_size->face,
-				 hb_font, &ftfont_info->matrix, direction);
-    }
-  else
-#endif  /* HAVE_HARFBUZZ */
-    {
-#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
-      OTF *otf = ftfont_get_otf (ftfont_info);
 
-      return ftfont_shape_by_flt (lgstring, font, ftfont_info->ft_size->face,
-				  otf, &ftfont_info->matrix);
-#endif  /* defined HAVE_M17N_FLT && defined HAVE_LIBOTF */
-    }
-  return make_fixnum (0);
+  return ftfont_shape_by_hb (lgstring, font, direction);
 }
 
-#endif /* (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ */
+#endif /* HAVE_HARFBUZZ */
 
 static const char *const ftfont_booleans [] = {
   ":antialias",
@@ -3046,7 +3080,7 @@ ftfont_filter_properties (Lisp_Object font, Lisp_Object alist)
 Lisp_Object
 ftfont_combining_capability (struct font *font)
 {
-#if defined HAVE_M17N_FLT || defined HAVE_HARFBUZZ
+#ifdef HAVE_M17N_FLT
   return Qt;
 #else
   return Qnil;
@@ -3073,7 +3107,7 @@ static struct font_driver const ftfont_driver =
 #ifdef HAVE_LIBOTF
   .otf_capability = ftfont_otf_capability,
 #endif
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
   .shape = ftfont_shape,
 #endif
 #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
@@ -3082,12 +3116,18 @@ static struct font_driver const ftfont_driver =
   .filter_properties = ftfont_filter_properties,
   .combining_capability = ftfont_combining_capability,
   };
+#ifdef HAVE_HARFBUZZ
+static struct font_driver fthbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 
 void
 syms_of_ftfont (void)
 {
   /* Symbolic type of this font-driver.  */
   DEFSYM (Qfreetype, "freetype");
+#ifdef HAVE_HARFBUZZ
+  DEFSYM (Qfreetypehb, "freetypehb");
+#endif	/* HAVE_HARFBUZZ */
 
   /* Fontconfig's generic families and their aliases.  */
   DEFSYM (Qmonospace, "monospace");
@@ -3114,4 +3154,12 @@ syms_of_ftfont_for_pdumper (void)
 {
   PDUMPER_RESET_LV (ft_face_cache, Qnil);
   register_font_driver (&ftfont_driver, NULL);
+#ifdef HAVE_HARFBUZZ
+  fthbfont_driver = ftfont_driver;
+  fthbfont_driver.type = Qfreetypehb;
+  fthbfont_driver.shape = fthbfont_shape;
+  fthbfont_driver.combining_capability = fthbfont_combining_capability;
+  fthbfont_driver.begin_hb_font = fthbfont_begin_hb_font;
+  register_font_driver (&fthbfont_driver, NULL);
+#endif	/* HAVE_HARFBUZZ */
 }
diff --git a/src/ftxfont.c b/src/ftxfont.c
index a549fd723bb..949ef4c503b 100644
--- a/src/ftxfont.c
+++ b/src/ftxfont.c
@@ -209,21 +209,13 @@ ftxfont_draw_background (struct frame *f, struct font *font, GC gc, int x, int y
 static Lisp_Object
 ftxfont_list (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object list = ftfont_list (f, spec), tail;
-
-  for (tail = list; CONSP (tail); tail = XCDR (tail))
-    ASET (XCAR (tail), FONT_TYPE_INDEX, Qftx);
-  return list;
+  return ftfont_list2 (f, spec, Qftx);
 }
 
 static Lisp_Object
 ftxfont_match (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object entity = ftfont_match (f, spec);
-
-  if (VECTORP (entity))
-    ASET (entity, FONT_TYPE_INDEX, Qftx);
-  return entity;
+  return ftfont_match2 (f, spec, Qftx);
 }
 
 static Lisp_Object
@@ -362,7 +354,7 @@ struct font_driver const ftxfont_driver =
   .otf_capability = ftfont_otf_capability,
 #endif
   .end_for_frame = ftxfont_end_for_frame,
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
   .shape = ftfont_shape,
 #endif
 #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
diff --git a/src/xfns.c b/src/xfns.c
index 2ceb55a30ad..50a430aa78c 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -3774,10 +3774,16 @@ This function is an internal primitive--use `make-frame' instead.  */)
 
 #ifdef USE_CAIRO
   register_font_driver (&ftcrfont_driver, f);
+#ifdef HAVE_HARFBUZZ
+  register_font_driver (&ftcrhbfont_driver, f);
+#endif	/* HAVE_HARFBUZZ */
 #else
 #ifdef HAVE_FREETYPE
 #ifdef HAVE_XFT
   register_font_driver (&xftfont_driver, f);
+#ifdef HAVE_HARFBUZZ
+  register_font_driver (&xfthbfont_driver, f);
+#endif
 #else	/* not HAVE_XFT */
   register_font_driver (&ftxfont_driver, f);
 #endif	/* not HAVE_XFT */
diff --git a/src/xftfont.c b/src/xftfont.c
index b636a759048..f7b87f96569 100644
--- a/src/xftfont.c
+++ b/src/xftfont.c
@@ -108,21 +108,13 @@ xftfont_get_colors (struct frame *f, struct face *face, GC gc,
 static Lisp_Object
 xftfont_list (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object list = ftfont_list (f, spec);
-
-  for (Lisp_Object tail = list; CONSP (tail); tail = XCDR (tail))
-    ASET (XCAR (tail), FONT_TYPE_INDEX, Qxft);
-  return list;
+  return ftfont_list2 (f, spec, Qxft);
 }
 
 static Lisp_Object
 xftfont_match (struct frame *f, Lisp_Object spec)
 {
-  Lisp_Object entity = ftfont_match (f, spec);
-
-  if (! NILP (entity))
-    ASET (entity, FONT_TYPE_INDEX, Qxft);
-  return entity;
+  return ftfont_match2 (f, spec, Qxft);
 }
 
 static FcChar8 ascii_printable[95];
@@ -311,10 +303,16 @@ xftfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
   /* We should not destroy PAT here because it is kept in XFTFONT and
      destroyed automatically when XFTFONT is closed.  */
   font_object = font_build_object (VECSIZE (struct font_info),
-				   Qxft, entity, size);
+				   AREF (entity, FONT_TYPE_INDEX),
+				   entity, size);
   ASET (font_object, FONT_FILE_INDEX, filename);
   font = XFONT_OBJECT (font_object);
   font->pixel_size = size;
+#ifdef HAVE_HARFBUZZ
+  if (EQ (AREF (font_object, FONT_TYPE_INDEX), Qxfthb))
+    font->driver = &xfthbfont_driver;
+  else
+#endif	/* HAVE_HARFBUZZ */
   font->driver = &xftfont_driver;
   font->encoding_charset = font->repertory_charset = -1;
 
@@ -649,7 +647,7 @@ xftfont_draw (struct glyph_string *s, int from, int to, int x, int y,
   return len;
 }
 
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
 static Lisp_Object
 xftfont_shape (Lisp_Object lgstring, Lisp_Object direction)
 {
@@ -739,6 +737,41 @@ xftfont_cached_font_ok (struct frame *f, Lisp_Object font_object,
   return ok;
 }
 
+#ifdef HAVE_HARFBUZZ
+
+static Lisp_Object
+xfthbfont_list (struct frame *f, Lisp_Object spec)
+{
+  return ftfont_list2 (f, spec, Qxfthb);
+}
+
+static Lisp_Object
+xfthbfont_match (struct frame *f, Lisp_Object spec)
+{
+  return ftfont_match2 (f, spec, Qxfthb);
+}
+
+static hb_font_t *
+xfthbfont_begin_hb_font (struct font *font, double *position_unit)
+{
+  struct font_info *xftfont_info = (struct font_info *) font;
+  FT_Face ft_face = XftLockFace (xftfont_info->xftfont);
+
+  xftfont_info->ft_size = ft_face->size;
+
+  return fthbfont_begin_hb_font (font, position_unit);
+}
+
+static void
+xfthbfont_end_hb_font (struct font *font, hb_font_t *hb_font)
+{
+  struct font_info *xftfont_info = (struct font_info *) font;
+
+  XftUnlockFace (xftfont_info->xftfont);
+}
+
+#endif	/* HAVE_HARFBUZZ */
+
 static void syms_of_xftfont_for_pdumper (void);
 
 struct font_driver const xftfont_driver =
@@ -763,7 +796,7 @@ struct font_driver const xftfont_driver =
   .otf_capability = ftfont_otf_capability,
 #endif
   .end_for_frame = xftfont_end_for_frame,
-#if (defined HAVE_M17N_FLT && defined HAVE_LIBOTF) || defined HAVE_HARFBUZZ
+#if defined HAVE_M17N_FLT && defined HAVE_LIBOTF
   .shape = xftfont_shape,
 #endif
 #ifdef HAVE_OTF_GET_VARIATION_GLYPHS
@@ -774,11 +807,17 @@ struct font_driver const xftfont_driver =
   .combining_capability = ftfont_combining_capability,
   .drop_xrender_surfaces = xftfont_drop_xrender_surfaces,
   };
+#ifdef HAVE_HARFBUZZ
+struct font_driver xfthbfont_driver;
+#endif	/* HAVE_HARFBUZZ */
 
 void
 syms_of_xftfont (void)
 {
   DEFSYM (Qxft, "xft");
+#ifdef HAVE_HARFBUZZ
+  DEFSYM (Qxfthb, "xfthb");
+#endif	/* HAVE_HARFBUZZ */
   DEFSYM (QChinting, ":hinting");
   DEFSYM (QCautohint, ":autohint");
   DEFSYM (QChintstyle, ":hintstyle");
@@ -799,4 +838,15 @@ static void
 syms_of_xftfont_for_pdumper (void)
 {
   register_font_driver (&xftfont_driver, NULL);
+#ifdef HAVE_HARFBUZZ
+  xfthbfont_driver = xftfont_driver;
+  xfthbfont_driver.type = Qxfthb;
+  xfthbfont_driver.list = xfthbfont_list;
+  xfthbfont_driver.match = xfthbfont_match;
+  xfthbfont_driver.shape = fthbfont_shape;
+  xfthbfont_driver.combining_capability = fthbfont_combining_capability;
+  xfthbfont_driver.begin_hb_font = xfthbfont_begin_hb_font;
+  xfthbfont_driver.end_hb_font = xfthbfont_end_hb_font;
+  register_font_driver (&xfthbfont_driver, NULL);
+#endif	/* HAVE_HARFBUZZ */
 }

Re: landing harfbuzz branch (Re: Status of multicolor fonts?)

[Alan Third]

On Fri, May 03, 2019 at 06:59:26PM +0900, mituharu@math.s.chiba-u.ac.jp wrote:
> I also tried adding the `mac-cthb' backend, but it is not included
> in the patch.

Is there any advantage to mac-cthb over the current coretext system?

Could it be ported to GNUstep? The current font backend is, in my
experience, not very good.

-- 
Alan Third

Re: landing harfbuzz branch (Re: Status of multicolor fonts?)

[mituharu]

> On Fri, May 03, 2019 at 06:59:26PM +0900, mituharu@math.s.chiba-u.ac.jp
> wrote:
>> I also tried adding the `mac-cthb' backend, but it is not included
>> in the patch.
>
> Is there any advantage to mac-cthb over the current coretext system?

Nothing I know of.  I just implemented it to see if FreeType
dependency is eliminated in ftfont_shape_by_hb (despite its
name).

> Could it be ported to GNUstep? The current font backend is, in my
> experience, not very good.

That would make sense.  There is no direct interface to create
hb_font_t object from NSFont, but it might be possible by
directly referring to the font file name.

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

Re: landing harfbuzz branch (Re: Status of multicolor fonts?)

[Eli Zaretskii]

> Date: Fri, 3 May 2019 18:59:26 +0900
> From: mituharu@math.s.chiba-u.ac.jp
> 
> The attached patch is against the harfbuzz branch, and it adds
> `xfthb' and `ftcrhb' backends that use HarfBuzz for shaping.  I
> also tried adding the `mac-cthb' backend, but it is not included
> in the patch.

Thanks!  Please push to the harfbuzz branch, I'd like people to try
this and report feedback.

The branch will need some documentation updates before it will be
ready to land on master.

> With the `ftcrhb' font backend, one can now display regional flag
> emojis:

What would we need to be able to display those emojis in the xfthb
backend?

Re: landing harfbuzz branch (Re: Status of multicolor fonts?)

[mituharu]

>> Date: Fri, 3 May 2019 18:59:26 +0900
>> From: mituharu@math.s.chiba-u.ac.jp
>>
>> The attached patch is against the harfbuzz branch, and it adds
>> `xfthb' and `ftcrhb' backends that use HarfBuzz for shaping.  I
>> also tried adding the `mac-cthb' backend, but it is not included
>> in the patch.
>
> Thanks!  Please push to the harfbuzz branch, I'd like people to try
> this and report feedback.

Done.

>> With the `ftcrhb' font backend, one can now display regional flag
>> emojis:
>
> What would we need to be able to display those emojis in the xfthb
> backend?

Xft does not support multicolor fonts, but text shaping itself
will work for the xfthb font backend and monochrome fonts that
support emoji flag sequences.  At least, "Noto Emoji" (not "Noto
Color Emoji") seems to work.

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

Re: landing harfbuzz branch (Re: Status of multicolor fonts?)

[Eli Zaretskii]

> Date: Sun, 5 May 2019 08:42:58 +0900
> From: mituharu@math.s.chiba-u.ac.jp
> Cc: emacs-devel@gnu.org
> 
> >> Date: Fri, 3 May 2019 18:59:26 +0900
> >> From: mituharu@math.s.chiba-u.ac.jp
> >>
> >> The attached patch is against the harfbuzz branch, and it adds
> >> `xfthb' and `ftcrhb' backends that use HarfBuzz for shaping.  I
> >> also tried adding the `mac-cthb' backend, but it is not included
> >> in the patch.
> >
> > Thanks!  Please push to the harfbuzz branch, I'd like people to try
> > this and report feedback.
> 
> Done.

Thanks.

> >> With the `ftcrhb' font backend, one can now display regional flag
> >> emojis:
> >
> > What would we need to be able to display those emojis in the xfthb
> > backend?
> 
> Xft does not support multicolor fonts, but text shaping itself
> will work for the xfthb font backend and monochrome fonts that
> support emoji flag sequences.  At least, "Noto Emoji" (not "Noto
> Color Emoji") seems to work.

You mean Xft cannot access the attributes of color fonts that are
needed to display color emoji?  Does HarfBuzz itself have interfaces
which could allow to access those attributes?

Or is the Xft problem something else?

Re: Status of multicolor fonts?

[Stefan Monnier]

> Now the cairo build on master can display multicolor font if linked
> with cairo >= 1.16.0.

BTW, I saw there's a work-in-progress Wayland port of Emacs out there:

    https://github.com/masm11/emacs

Has anyone taken a look at it?


        Stefan "who knows very little about those things"

Re: Status of multicolor fonts?

[Yuri Khan]

On Wed, Dec 16, 2015 at 7:40 PM, Clément Pit--Claudel
<clement.pit@gmail.com> wrote:

> Multicolor fonts seem to be becoming popular, especially for representing Emoji.

Oh what the world is coming to. Whatever next, animated fonts?

Re: Status of multicolor fonts?

[Elias Mårtenson]

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

On 16 December 2015 at 22:37, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Wed, Dec 16, 2015 at 7:40 PM, Clément Pit--Claudel
> <clement.pit@gmail.com> wrote:
>
> > Multicolor fonts seem to be becoming popular, especially for
> representing Emoji.
>
> Oh what the world is coming to. Whatever next, animated fonts?
>

I hear you, and agree with you. But as a developer of a chat application
(like Slack, but free) which also has an Emacs client, colour fonts in
Emacs would be appreciated.

What I'm trying to say is that the state of fonts is what it is, and Emacs
should support it for those who wants it.

That said, since I have yet to actually contributed to Emacs core, take
this post for what it is, just a data point from someone who would see
immediate benefit from it.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1286 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> Date: Wed, 16 Dec 2015 23:32:36 +0800
> From: Elias Mårtenson <lokedhs@gmail.com>
> Cc: Clément Pit--Claudel <clement.pit@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> I hear you, and agree with you. But as a developer of a chat application (like
> Slack, but free) which also has an Emacs client, colour fonts in Emacs would be
> appreciated.

If your application needs that, you don't have to wait for this to be
supported in the core.  It should be very easy to write Lisp code that
generated faces with specific colors using the emoji characters and
the variation selectors as the key.  You should find the necessary
information here:

  http://www.unicode.org/versions/Unicode8.0.0/ch22.pdf
  http://unicode.org/reports/tr51/
  http://unicode.org/emoji/charts/index.html
  http://unicode.org/Public/emoji/latest/emoji-data.txt
  http://unicode.org/Public/emoji/latest/emoji-sequences.txt
  http://unicode.org/Public/emoji/latest/emoji-zwj-sequences.txt

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 10:48 AM, Eli Zaretskii wrote:
>> Date: Wed, 16 Dec 2015 23:32:36 +0800
>> From: Elias Mårtenson <lokedhs@gmail.com>
>> Cc: Clément Pit--Claudel <clement.pit@gmail.com>,
>> 	Emacs developers <emacs-devel@gnu.org>
>>
>> I hear you, and agree with you. But as a developer of a chat application (like
>> Slack, but free) which also has an Emacs client, colour fonts in Emacs would be
>> appreciated.
> 
> If your application needs that, you don't have to wait for this to be
> supported in the core.  It should be very easy to write Lisp code that
> generated faces with specific colors using the emoji characters and
> the variation selectors as the key.  You should find the necessary
> information here:
> 
>   http://www.unicode.org/versions/Unicode8.0.0/ch22.pdf
>   http://unicode.org/reports/tr51/
>   http://unicode.org/emoji/charts/index.html
>   http://unicode.org/Public/emoji/latest/emoji-data.txt
>   http://unicode.org/Public/emoji/latest/emoji-sequences.txt
>   http://unicode.org/Public/emoji/latest/emoji-zwj-sequences.txt

I may have misunderstood you, Eli, but I don't think this would work: the Emoji in the fonts that I was discussing are not monochrome.
On the other hand, it is quite possible to leverage Emacs' support for inline graphics to replace certain unicode characters or character sequences with multicolor image renditions.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> Cc: yuri.v.khan@gmail.com, emacs-devel@gnu.org
> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Wed, 16 Dec 2015 11:03:07 -0500
> 
> >   http://www.unicode.org/versions/Unicode8.0.0/ch22.pdf
> >   http://unicode.org/reports/tr51/
> >   http://unicode.org/emoji/charts/index.html
> >   http://unicode.org/Public/emoji/latest/emoji-data.txt
> >   http://unicode.org/Public/emoji/latest/emoji-sequences.txt
> >   http://unicode.org/Public/emoji/latest/emoji-zwj-sequences.txt
> 
> I may have misunderstood you, Eli, but I don't think this would work: the Emoji in the fonts that I was discussing are not monochrome.

Read the stuff I pointed to: each emoji has a B&W variant (which is
what you get from Emacs now) and color variants, selected by variation
selectors.

> On the other hand, it is quite possible to leverage Emacs' support for inline graphics to replace certain unicode characters or character sequences with multicolor image renditions.

Yes, but that's not "emoji support" in my book.

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 12:10 PM, Eli Zaretskii wrote:
>> Cc: yuri.v.khan@gmail.com, emacs-devel@gnu.org
>> From: Clément Pit--Claudel <clement.pit@gmail.com>
>> Date: Wed, 16 Dec 2015 11:03:07 -0500
>>
>>>   http://www.unicode.org/versions/Unicode8.0.0/ch22.pdf
>>>   http://unicode.org/reports/tr51/
>>>   http://unicode.org/emoji/charts/index.html
>>>   http://unicode.org/Public/emoji/latest/emoji-data.txt
>>>   http://unicode.org/Public/emoji/latest/emoji-sequences.txt
>>>   http://unicode.org/Public/emoji/latest/emoji-zwj-sequences.txt
>>
>> I may have misunderstood you, Eli, but I don't think this would work: the Emoji in the fonts that I was discussing are not monochrome.
> 
> Read the stuff I pointed to: each emoji has a B&W variant (which is
> what you get from Emacs now) and color variants, selected by variation
> selectors.

Thanks Eli. I'm rather familiar with these documents. But my question was not about this; it was about fonts that embed truly multicolor images for specific codepoints (support for variation selectors is another question entirely, I believe). There are various implementations of multicolor fonts, as pointed out by the document that I originally linked to. For example, Apple does it by packaging a collection of PNGs and calling that a font. Microsoft does it with multiple layers of single-color SVGs. I was curious to know whether Emacs supports any this, and on which platforms.

From some web searches, it seems that Emacs definitely does support the "PNG packages as a font" technology developed Apple, in the native port of Emacs to MacOS. I'm not sure who implemented this support, and who maintains it. Perhaps the insight of that person would be useful in generalizing this feature to other platforms that Emacs runs on.

Clément


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Elias Mårtenson]

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

On 16 December 2015 at 23:48, Eli Zaretskii <eliz@gnu.org> wrote:

If your application needs that, you don't have to wait for this to be
> supported in the core.  It should be very easy to write Lisp code that
> generated faces with specific colors using the emoji characters and
> the variation selectors as the key.  You should find the necessary
> information here:


I know this very well, but the application doesn't really *need* colour
emoji per se, and I don't want to write code (and provide images) to work
around this. All I was saying was that colour support would have immediate
benefits to my application.

I'd be happy to work on supporting this myself, but my previous attempts at
doing something interesting with the graphics code has left me somewhat
humbled by my failure.

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

Re: Status of multicolor fonts?

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:
> If your application needs that, you don't have to wait for this to be
> supported in the core.  It should be very easy to write Lisp code that
> generated faces with specific colors

I'm not sure if you understand the feature being requested. This is not
a font that specifies a foreground and background color per character,
it is a font that defines a character as a full-color graphic image
(e.g. the US flag in red, white, and blue with shadows and highlights,
though flags specifically are ligatures of two characters)

The variation selectors are specifically to replace the "skin color"
(typically yellow by default on the fonts that support them) with a
selected natural human skin color. I think they're actually implemented
by selecting another graphic entirely, since some implementations also
have different hair colors.

Re: Status of multicolor fonts?

[David Kastrup]

Random832 <random832@fastmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>> If your application needs that, you don't have to wait for this to be
>> supported in the core.  It should be very easy to write Lisp code that
>> generated faces with specific colors
>
> I'm not sure if you understand the feature being requested. This is not
> a font that specifies a foreground and background color per character,
> it is a font that defines a character as a full-color graphic image
> (e.g. the US flag in red, white, and blue with shadows and highlights,
> though flags specifically are ligatures of two characters)
>
> The variation selectors are specifically to replace the "skin color"
> (typically yellow by default on the fonts that support them) with a
> selected natural human skin color. I think they're actually implemented
> by selecting another graphic entirely, since some implementations also
> have different hair colors.

Requiring colored font support for the sake of supporting racist
subdivision of "emojis".  Whoever sold that idea to the Unicode
consortium could certainly become a career lobbyist if he isn't yet.

Couldn't they have found a more dignified reason for putting forward
this technical challenge?

-- 
David Kastrup

Re: Status of multicolor fonts?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I suggest that we give low priority to this feature.
If someone wants to implement it and does a good job, we can
accept it, but otherwise we don't care.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Status of multicolor fonts?

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> I suggest that we give low priority to this feature. If someone wants to
> implement it and does a good job, we can accept it, but otherwise we don't
> care.

Agreed.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: Status of multicolor fonts?

[Eli Zaretskii]

> From: Random832 <random832@fastmail.com>
> Date: Wed, 16 Dec 2015 11:41:40 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > If your application needs that, you don't have to wait for this to be
> > supported in the core.  It should be very easy to write Lisp code that
> > generated faces with specific colors
> 
> I'm not sure if you understand the feature being requested.

I'm not sure why are you not sure.

> This is not a font that specifies a foreground and background color
> per character, it is a font that defines a character as a full-color
> graphic image (e.g. the US flag in red, white, and blue with shadows
> and highlights, though flags specifically are ligatures of two
> characters)

I'm quite sure you know that Emacs displays character glyphs by
drawing the background and foreground separately, and it sets the
colors of each one according to the attributes of the current face.
How, then, will the full-color image be displayed, if we override the
colors it might specify?

> The variation selectors are specifically to replace the "skin color"
> (typically yellow by default on the fonts that support them) with a
> selected natural human skin color. I think they're actually implemented
> by selecting another graphic entirely, since some implementations also
> have different hair colors.

Yes, I know.

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 12:17 PM, Eli Zaretskii wrote:
>>> This is not a font that specifies a foreground and background 
>>> color per character, it is a font that defines a character as a 
>>> full-color graphic image (e.g. the US flag in red, white, and 
>>> blue with shadows and highlights, though flags specifically are 
>>> ligatures of two characters)
> I'm quite sure you know that Emacs displays character glyphs by 
> drawing the background and foreground separately, and it sets the 
> colors of each one according to the attributes of the current face. 
> How, then, will the full-color image be displayed, if we override
> the colors it might specify?

We wouldn't override the colors of the image; we would just display it, without modifications. The background color of the face is still relevant, but the foreground would not be (except for underlines, for example).

Other characteristics of the face would be ignored as well, such as its weight.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Wed, 16 Dec 2015 13:31:04 -0500
> 
> > I'm quite sure you know that Emacs displays character glyphs by 
> > drawing the background and foreground separately, and it sets the 
> > colors of each one according to the attributes of the current face. 
> > How, then, will the full-color image be displayed, if we override
> > the colors it might specify?
> 
> We wouldn't override the colors of the image; we would just display it, without modifications. The background color of the face is still relevant, but the foreground would not be (except for underlines, for example).

I understand the theory, but that's not how the code currently works,
AFAIU.  It will have to be modified to support this.  I also suspect
that some support from the font back-end (a.k.a. "shaping engine")
will be required, perhaps in using special APIs or activating some
special options, in order to get all this working as expected.

Re: Status of multicolor fonts?

[Random832]

Eli Zaretskii <eliz@gnu.org> writes:
> I'm quite sure you know that Emacs displays character glyphs by
> drawing the background and foreground separately, and it sets the
> colors of each one according to the attributes of the current face.
> How, then, will the full-color image be displayed, if we override the
> colors it might specify?

AIUI, the way this is done is that the background is drawn, then
the full color image (which is transparent so the background can
show through) is drawn on top of the background, and the
foreground color is ignored. None of the colors (except the
background) can be overridden. I suppose you could have it use
the foreground color for the outline and for things like the
"square" icons that are typically blue, but that doesn't seem to
be done.

Re: Status of multicolor fonts?

[Clément Pit--Claudel]

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

On 12/16/2015 09:37 AM, Yuri Khan wrote:
> On Wed, Dec 16, 2015 at 7:40 PM, Clément Pit--Claudel
> <clement.pit@gmail.com> wrote:
> 
>> Multicolor fonts seem to be becoming popular, especially for representing Emoji.
> 
> Oh what the world is coming to. Whatever next, animated fonts?

Emacs already has support for displaying images inline, and there exists Emacs packages for replacing certain Unicode characters with images automatically (thus emulating support for Emoji fonts). From there, it doesn't seem much of a stretch to discuss direct support for Emoji fonts in Emacs.

In my case, they would make status flags in mu4e much more readable. But of course I can use inline images for the same purpose.

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Status of multicolor fonts?

[Eli Zaretskii]

> From: Clément Pit--Claudel <clement.pit@gmail.com>
> Date: Wed, 16 Dec 2015 11:00:18 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> Emacs already has support for displaying images inline, and there exists Emacs packages for replacing certain Unicode characters with images automatically (thus emulating support for Emoji fonts). From there, it doesn't seem much of a stretch to discuss direct support for Emoji fonts in Emacs.

Replacing certain characters with images is easy, and can be done in
Emacs already; you just need to code that explicitly in Lisp.  But
having this done automatically by the display engine whenever it sees
a certain codepoint is something else entirely.

IOW, the ability to display today images instead of some text is not
something that can evolve into automatic support for these characters
on the display engine level.

Re: Status of multicolor fonts?

[David De La Harpe Golden]

On 16/12/15 14:37, Yuri Khan wrote:
> On Wed, Dec 16, 2015 at 7:40 PM, Clément Pit--Claudel
> <clement.pit@gmail.com> wrote:
>
>> Multicolor fonts seem to be becoming popular, especially for representing Emoji.
>
> Oh what the world is coming to. Whatever next, animated fonts?
>

As a historical note, "ColorFonts" and, yes, "AnimFonts" were in use on 
the Amiga many years ago now [1][2] - for video titling, presentations, 
etc.  At the time they were implemented as bitmap fonts, but color and 
animated outline fonts on more modern devices are an obvious natural 
development...

[1] http://www.amigaforever.com/classic/internet/
[2] http://www.pcmuseum.ca/details.asp?id=38483