bug#72268: 31.0.50; Color emoji rendering

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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



Hi,

With emacs configured as below, I have a weird rendering for color
emojis:

[-- Attachment #2: 2024-07-24T10:54+0200.png --]
[-- Type: image/png, Size: 62425 bytes --]

[-- Attachment #3: Type: text/plain, Size: 9149 bytes --]



In GNU Emacs 31.0.50 (build 37, x86_64-unknown-openbsd7.5) of 2024-07-24
 built on computer
Repository revision: 135ce96f1efd051c7bdd1a95670465a09502fa55
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: OpenBSD computer 7.5 GENERIC.MP#198 amd64

Configured using:
 'configure CC=egcc CPPFLAGS=-I/usr/local/include
 LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
 --bindir=/home/manuel/bin --with-x-toolkit=no --without-cairo
 --without-compress-install'

Configured features:
DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF
LIBXML2 MODULES NOTIFY KQUEUE OLDXMENU PDUMPER PNG RSVG SQLITE3 THREADS
TIFF TREE_SITTER WEBP X11 XDBE XFT XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  pdf-occur-dired-minor-mode: t
  gnus-dired-mode: t
  display-time-mode: t
  display-battery-mode: t
  desktop-save-mode: t
  exwm-randr-mode: t
  server-mode: t
  electric-pair-mode: t
  override-global-mode: t
  repeat-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/manuel/prog/elisp/exwm/exwm-randr hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-randr
/home/manuel/prog/elisp/exwm/exwm hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm
/home/manuel/prog/elisp/exwm/exwm-xsettings hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-xsettings
/home/manuel/prog/elisp/exwm/exwm-xim hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-xim
/home/manuel/prog/elisp/exwm/exwm-workspace hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-workspace
/home/manuel/prog/elisp/exwm/exwm-systemtray hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-systemtray
/home/manuel/prog/elisp/exwm/exwm-manage hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-manage
/home/manuel/prog/elisp/exwm/exwm-layout hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-layout
/home/manuel/prog/elisp/exwm/exwm-input hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-input
/home/manuel/prog/elisp/exwm/exwm-floating hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-floating
/home/manuel/prog/elisp/exwm/exwm-core hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-core
/home/manuel/prog/elisp/exwm/exwm-config hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-config
/home/manuel/prog/elisp/exwm/exwm-background hides /home/manuel/.emacs.d/elpa/exwm-0.31/exwm-background
/home/manuel/.emacs.d/elpa/ef-themes-1.7.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/31.0.50/lisp/theme-loaddefs

Features:
(shadow emacsbug help-fns radix-tree descr-text wdired gnus-dup
display-line-numbers debbugs-gnu debbugs-compat debbugs soap-client
rng-xsd rng-dt rng-util xsd-regexp debbugs-browse add-log vc-hg vc-bzr
vc-src vc-sccs vc-svn term ehelp pulse mailalias smtpmail gnus-delay
gnus-draft sort gnus-cite flow-fill mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check gnus-bcklg
gnus-async qp gnus-ml tramp-cmds tramp-cache time-stamp tramp-sh
gnus-topic mm-archive url-cache utf-7 imap rfc2104 nndoc nndraft nnmh
network-stream nnfolder nnml gnus-agent gnus-srvr gnus-score score-mode
nnvirtual nntp gnus-cache nnrss pdf-history pdf-outline pdf-links
pdf-annot facemenu pdf-sync org-indent org-agenda texinfo
texinfo-loaddefs view flymake-cc flymake warnings python conf-mode
vc-cvs vc-rcs log-view pcvs-util make-mode oc-basic org-element
org-persist org-id org-element-ast inline avl-tree ol-eww eww url-queue
mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview
doc-view filenotify ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi
gnus-icalendar org-capture org-refile org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete org-list
org-footnote org-faces org-entities org-version ob-emacs-lisp ob-core
ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc
org-loaddefs org-compat org-macs emacs-news-mode whitespace sh-script
smie treesit executable mule-util on-screen gud bug-reference pdf-occur
ibuf-ext ibuffer ibuffer-loaddefs tablist tablist-filter
semantic/wisent/comp semantic/wisent semantic/wisent/wisent
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local cedet pdf-isearch let-alist pdf-misc imenu
pdf-tools cus-edit cus-start pdf-view bookmark jka-compr pdf-cache
pdf-info tq pdf-util pdf-macs image-mode exif gnus-dired vc-dir ewoc vc
vc-git diff-mode track-changes vc-dispatcher time battery cus-load
desktop frameset exwm-randr xcb-randr exwm exwm-input xcb-keysyms
xcb-xkb exwm-manage exwm-floating xcb-cursor xcb-render exwm-layout
exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb xcb-xproto xcb-types
xcb-debug server ef-kassio-theme ef-themes modus-operandi-theme
modus-themes zone speed-type url-http url-auth url-gw nsm ytdious
mpdired transmission color calc-bin calc-ext calc calc-loaddefs rect
calc-macs supercite regi ebdb-gnus gnus-msg gnus-art mm-uu mml2015
mm-view mml-smime smime gnutls dig gnus-sum shr pixel-fill kinsoku
url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml
gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int
gnus-range gnus-win ebdb-message message sendmail yank-media puny rfc822
mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums gmm-utils mailheader
ebdb-mua ebdb-com crm ebdb-format ebdb mailabbrev eieio-opt speedbar
ezimage dframe find-func eieio-base timezone icalendar gnus nnheader
gnus-util mail-utils range mm-util mail-prsvr wid-edit web-mode derived
disp-table erlang-start skeleton cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs slime-asdf grep
slime-tramp tramp rx trampver tramp-integration files-x tramp-message
tramp-compat xdg shell pcomplete parse-time iso8601 time-date
format-spec tramp-loaddefs slime-fancy slime-indentation slime-cl-indent
cl-indent slime-trace-dialog slime-fontifying-fu slime-package-fu
slime-references slime-compiler-notes-tree advice slime-scratch
slime-presentations bridge slime-macrostep macrostep compat
slime-mdot-fu slime-enclosing-context slime-fuzzy slime-fancy-trace
slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc
slime-repl slime-parse slime apropos compile text-property-search etags
fileloop generator xref project arc-mode archive-mode noutline outline
pp comint ansi-osc ansi-color ring hyperspec thingatpt elec-pair edmacro
kmacro use-package-bind-key bind-key appt diary-lib diary-loaddefs
cal-menu calendar cal-loaddefs pcase dired-x dired-aux dired
dired-loaddefs use-package-core repeat easy-mmode calfw-autoloads
calfw-cal-autoloads calfw-org-autoloads debbugs-autoloads ebdb-autoloads
cl-extra help-mode ef-themes-autoloads exwm-autoloads
hyperbole-autoloads kotl-autoloads hact set hhist on-screen-autoloads
osm-autoloads pdf-tools-autoloads rust-mode-autoloads info
slime-autoloads macrostep-autoloads speed-type-autoloads
tablist-autoloads transmission-autoloads xelb-autoloads
ytdious-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt
gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
touch-screen tool-bar dnd fontset image regexp-opt fringe tabulated-list
replace newcomment text-mode lisp-mode prog-mode register page tab-bar
menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse
jit-lock font-lock syntax font-core term/tty-colors frame minibuffer
nadvice seq simple cl-generic indonesian philippine cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind kqueue lcms2 dynamic-setting system-font-setting
font-render-setting xinput2 x multi-tty move-toolbar
make-network-process emacs)

Memory information:
((conses 16 1213891 456069) (symbols 48 75053 16)
 (strings 32 349900 4926) (string-bytes 1 11815543)
 (vectors 16 190913) (vector-slots 8 2622631 136146)
 (floats 8 828 375) (intervals 56 43854 2390) (buffers 992 189))

-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> Date: Wed, 24 Jul 2024 10:59:03 +0200
> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> With emacs configured as below, I have a weird rendering for color
> emojis:

I don't think we support color Emoji without Cairo.  Po Lu, am I
right?

If you use a black-and-white Emoji font, do Emoji display correctly?

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 24 Jul 2024 10:59:03 +0200
>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> With emacs configured as below, I have a weird rendering for color
>> emojis:
>
> I don't think we support color Emoji without Cairo.  Po Lu, am I
> right?
>
> If you use a black-and-white Emoji font, do Emoji display correctly?

Yes they do.  The black and white "Noto Emoji" are correctly displayed.
FWIW, a Cairo build is worse in this regard: no Emoji are displayed at
all (black and white or color).
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Manuel Giraud <manuel@ledu-giraud.fr> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Date: Wed, 24 Jul 2024 10:59:03 +0200
>>> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>> 
>>> With emacs configured as below, I have a weird rendering for color
>>> emojis:
>>
>> I don't think we support color Emoji without Cairo.  Po Lu, am I
>> right?
>>
>> If you use a black-and-white Emoji font, do Emoji display correctly?
>
> Yes they do.  The black and white "Noto Emoji" are correctly displayed.
> FWIW, a Cairo build is worse in this regard: no Emoji are displayed at
> all (black and white or color).

Since recent releases of Xft are supposed to support color Emoji, please
upgrade to the latest release, 2.3.8, or if you have installed this
version, report this glitch to their developers.

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: Po Lu <luangruo@yahoo.com>,  72268@debbugs.gnu.org
> Date: Wed, 24 Jul 2024 13:59:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Wed, 24 Jul 2024 10:59:03 +0200
> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> >> 
> >> With emacs configured as below, I have a weird rendering for color
> >> emojis:
> >
> > I don't think we support color Emoji without Cairo.  Po Lu, am I
> > right?
> >
> > If you use a black-and-white Emoji font, do Emoji display correctly?
> 
> Yes they do.  The black and white "Noto Emoji" are correctly displayed.

I think this is all you can expect without Cairo.

> FWIW, a Cairo build is worse in this regard: no Emoji are displayed at
> all (black and white or color).

That's strange, because AFAIK users on GNU/Linux do report very good
results with Cairo and color Emoji fonts.  Did you try Noto Color
Emoji (which is the default font for Emoji in Emacs)?

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: Po Lu <luangruo@yahoo.com>,  72268@debbugs.gnu.org
>> Date: Wed, 24 Jul 2024 13:59:10 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Wed, 24 Jul 2024 10:59:03 +0200
>> >> From:  Manuel Giraud via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> >> 
>> >> With emacs configured as below, I have a weird rendering for color
>> >> emojis:
>> >
>> > I don't think we support color Emoji without Cairo.  Po Lu, am I
>> > right?
>> >
>> > If you use a black-and-white Emoji font, do Emoji display correctly?
>> 
>> Yes they do.  The black and white "Noto Emoji" are correctly displayed.
>
> I think this is all you can expect without Cairo.
>
>> FWIW, a Cairo build is worse in this regard: no Emoji are displayed at
>> all (black and white or color).
>
> That's strange, because AFAIK users on GNU/Linux do report very good
> results with Cairo and color Emoji fonts.  Did you try Noto Color
> Emoji (which is the default font for Emoji in Emacs)?

Yes.  I think that I'd better try to resolve this issue (w/ a Cairo
build) than try to solve it in Xft.

Currently, with a Cairo build, Emoji are displayed with empty boxes (not
the boxed hex representation, just empty ones).  'C-u C-x =' says it is
"Noto Color Emoji".  I'm using cairo 1.18.0.
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
> Date: Wed, 24 Jul 2024 14:58:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's strange, because AFAIK users on GNU/Linux do report very good
> > results with Cairo and color Emoji fonts.  Did you try Noto Color
> > Emoji (which is the default font for Emoji in Emacs)?
> 
> Yes.  I think that I'd better try to resolve this issue (w/ a Cairo
> build) than try to solve it in Xft.
> 
> Currently, with a Cairo build, Emoji are displayed with empty boxes (not
> the boxed hex representation, just empty ones).  'C-u C-x =' says it is
> "Noto Color Emoji".  I'm using cairo 1.18.0.

Please show what "C-u C-x =" says when point is on one of these Emoji.

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
>> Date: Wed, 24 Jul 2024 14:58:55 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > That's strange, because AFAIK users on GNU/Linux do report very good
>> > results with Cairo and color Emoji fonts.  Did you try Noto Color
>> > Emoji (which is the default font for Emoji in Emacs)?
>> 
>> Yes.  I think that I'd better try to resolve this issue (w/ a Cairo
>> build) than try to solve it in Xft.
>> 
>> Currently, with a Cairo build, Emoji are displayed with empty boxes (not
>> the boxed hex representation, just empty ones).  'C-u C-x =' says it is
>> "Noto Color Emoji".  I'm using cairo 1.18.0.
>
> Please show what "C-u C-x =" says when point is on one of these Emoji.

Here is what I see:

[-- Attachment #2: 2024-07-24T15:45+0200.png --]
[-- Type: image/png, Size: 58404 bytes --]

[-- Attachment #3: Type: text/plain, Size: 617 bytes --]


M-x emacs-build-description:
In GNU Emacs 31.0.50 (build 2, x86_64-unknown-openbsd7.5, cairo version
 1.18.0) of 2024-07-24 built on computer
Repository revision: 135ce96f1efd051c7bdd1a95670465a09502fa55
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: OpenBSD computer 7.5 GENERIC.MP#198 amd64

Configured using:
 'configure CC=egcc CPPFLAGS=-I/usr/local/include
 LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
 --bindir=/home/manuel/bin --with-x-toolkit=no --with-cairo
 --without-compress-install'
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
> Date: Wed, 24 Jul 2024 15:48:39 +0200
> 
> > Please show what "C-u C-x =" says when point is on one of these Emoji.
> 
> Here is what I see:

Thanks.  Very strange.  Can someone who uses Cairo on GNU/Linux
reproduce this?

Cairo 1.18.0 is a recent new major release, maybe it's a problem with
that version?  Does anyone else use it and sees correct color Emoji
display?

bug#72268: 31.0.50; Color emoji rendering

[Robert Pluim]

>>>>> On Wed, 24 Jul 2024 17:15:44 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Manuel Giraud <manuel@ledu-giraud.fr>
    >> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
    >> Date: Wed, 24 Jul 2024 15:48:39 +0200
    >> 
    >> > Please show what "C-u C-x =" says when point is on one of these Emoji.
    >> 
    >> Here is what I see:

    Eli> Thanks.  Very strange.  Can someone who uses Cairo on GNU/Linux
    Eli> reproduce this?

    Eli> Cairo 1.18.0 is a recent new major release, maybe it's a problem with
    Eli> that version?  Does anyone else use it and sees correct color Emoji
    Eli> display?

My Fedora install uses Cairo 1.18.0, and I see emoji fine in a
'--with-x-toolkit=no --with-cairo' build. Although thatʼs using
XWayland, not X11.

I can offer the following from etc/PROBLEMS:

    ** Characters are displayed as empty boxes or with wrong font under X.

    *** This may be due to your local fontconfig customization.
    Try removing or moving aside "$XDG_CONFIG_HOME/fontconfig/conf.d" and
    "$XDG_CONFIG_HOME/fontconfig/fonts.conf"
    ($XDG_CONFIG_HOME is treated as "~/.config" if not set)

Robert
-- 

bug#72268: 31.0.50; Color emoji rendering

[Visuwesh]

[புதன் ஜூலை 24, 2024] Robert Pluim wrote:

>>>>>> On Wed, 24 Jul 2024 17:15:44 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Manuel Giraud <manuel@ledu-giraud.fr>
>     >> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
>     >> Date: Wed, 24 Jul 2024 15:48:39 +0200
>     >> 
>     >> > Please show what "C-u C-x =" says when point is on one of these Emoji.
>     >> 
>     >> Here is what I see:
>
>     Eli> Thanks.  Very strange.  Can someone who uses Cairo on GNU/Linux
>     Eli> reproduce this?
>
>     Eli> Cairo 1.18.0 is a recent new major release, maybe it's a problem with
>     Eli> that version?  Does anyone else use it and sees correct color Emoji
>     Eli> display?
>
> My Fedora install uses Cairo 1.18.0, and I see emoji fine in a
> '--with-x-toolkit=no --with-cairo' build. Although thatʼs using
> XWayland, not X11.

I cannot reproduce in --with-x-toolkit=lucid --with-cairo build and
cairo 1.18.0.  Same with --with-x-toolkit=no.  This is in Xorg.

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Wed, 24 Jul 2024 17:15:44 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Manuel Giraud <manuel@ledu-giraud.fr>
>     >> Cc: luangruo@yahoo.com,  72268@debbugs.gnu.org
>     >> Date: Wed, 24 Jul 2024 15:48:39 +0200
>     >> 
>     >> > Please show what "C-u C-x =" says when point is on one of these Emoji.
>     >> 
>     >> Here is what I see:
>
>     Eli> Thanks.  Very strange.  Can someone who uses Cairo on GNU/Linux
>     Eli> reproduce this?
>
>     Eli> Cairo 1.18.0 is a recent new major release, maybe it's a problem with
>     Eli> that version?  Does anyone else use it and sees correct color Emoji
>     Eli> display?
>
> My Fedora install uses Cairo 1.18.0, and I see emoji fine in a
> '--with-x-toolkit=no --with-cairo' build. Although thatʼs using
> XWayland, not X11.
>
> I can offer the following from etc/PROBLEMS:

Thanks.  I've try moving the system "fontconfig/conf.d" out of the way
but it does not change anything.  FWIW, I can display those Emoji (in
color) in Firefox but not xfce4-terminal.  So maybe, it is not an Emacs
bug.
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Robert Pluim]

>>>>> On Wed, 24 Jul 2024 20:00:48 +0200, Manuel Giraud via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:


    Manuel> Thanks.  I've try moving the system "fontconfig/conf.d" out of the way
    Manuel> but it does not change anything.  FWIW, I can display those Emoji (in
    Manuel> color) in Firefox but not xfce4-terminal.  So maybe, it is not an Emacs
    Manuel> bug.
    Manuel> -- 
    Manuel> Manuel Giraud

Thatʼs using the 'Twemoji Mozillaʼ font, right? That font comes with
warnings about needing to support layered colour fonts for it to work
correctly. I doubt Emacs has explicit support for that.

Robert
-- 

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Hi,

I've search about this issue and found the following link:
https://old.reddit.com/r/openbsd/comments/1atanzd/color_emoji_not_shown/

When I apply the recipe describe by sthen@ here, I can make color emoji
to work in Emacs (and probably other applications).  Therefore, I
propose that we add the following patch to etc/PROBLEMS.  WDYT?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-unsupported-color-Emoji-on-OpenBSD.patch --]
[-- Type: text/x-patch, Size: 1076 bytes --]

From a7bdb0bb6b5071d1c8154ffa96f0585bb87bec46 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Thu, 25 Jul 2024 13:57:59 +0200
Subject: [PATCH] Document unsupported color Emoji on OpenBSD

Bug#72268

* etc/PROBLEMS (Runtime problems related to font handling):
Document unsupported color Emoji on OpenBSD.
---
 etc/PROBLEMS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index f8fb9f90c0b..226b90e1265 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1274,6 +1274,13 @@ Emacs will select some other font instead.
 The only workaround is not to choose such font variants as the default
 font when running Emacs on MS-Windows.
 
+** On OpenBSD, color Emoji are not supported.
+
+The system's FreeType library is not built with libpng support, so it
+can't display compressed colour emoji.  This is due to the fact that, on
+OpenBSD, libpng is provided through ports and that a base component
+cannot depend on that.
+
 * Internationalization problems
 
 ** M-{ does not work on a Spanish PC keyboard.
-- 
2.45.2


[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Robert Pluim]

>>>>> On Thu, 25 Jul 2024 15:36:33 +0200, Manuel Giraud <manuel@ledu-giraud.fr> said:

    Manuel> Hi,
    Manuel> I've search about this issue and found the following link:
    Manuel> https://old.reddit.com/r/openbsd/comments/1atanzd/color_emoji_not_shown/

    Manuel> When I apply the recipe describe by sthen@ here, I can make color emoji
    Manuel> to work in Emacs (and probably other applications).  Therefore, I
    Manuel> propose that we add the following patch to etc/PROBLEMS.  WDYT?

Looks good to me. Should we add a link to the workaround? (also,
someone more pedantic than me might prefer the spelling 'color' ;-))

    Manuel> From a7bdb0bb6b5071d1c8154ffa96f0585bb87bec46 Mon Sep 17 00:00:00 2001
    Manuel> From: Manuel Giraud <manuel@ledu-giraud.fr>
    Manuel> Date: Thu, 25 Jul 2024 13:57:59 +0200
    Manuel> Subject: [PATCH] Document unsupported color Emoji on OpenBSD

    Manuel> Bug#72268

    Manuel> * etc/PROBLEMS (Runtime problems related to font handling):
    Manuel> Document unsupported color Emoji on OpenBSD.
    Manuel> ---
    Manuel>  etc/PROBLEMS | 7 +++++++
    Manuel>  1 file changed, 7 insertions(+)

    Manuel> diff --git a/etc/PROBLEMS b/etc/PROBLEMS
    Manuel> index f8fb9f90c0b..226b90e1265 100644
    Manuel> --- a/etc/PROBLEMS
    Manuel> +++ b/etc/PROBLEMS
    Manuel> @@ -1274,6 +1274,13 @@ Emacs will select some other font instead.
    Manuel>  The only workaround is not to choose such font variants as the default
    Manuel>  font when running Emacs on MS-Windows.
 
    Manuel> +** On OpenBSD, color Emoji are not supported.
    Manuel> +
    Manuel> +The system's FreeType library is not built with libpng support, so it
    Manuel> +can't display compressed colour emoji.  This is due to the fact that, on
    Manuel> +OpenBSD, libpng is provided through ports and that a base component
    Manuel> +cannot depend on that.
    Manuel> +
    Manuel>  * Internationalization problems
 
    Manuel>  ** M-{ does not work on a Spanish PC keyboard.
    Manuel> -- 
    Manuel> 2.45.2


    Manuel> -- 
    Manuel> Manuel Giraud


Robert
-- 

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: luangruo@yahoo.com,  Eli Zaretskii <eliz@gnu.org>,  72268@debbugs.gnu.org
> Date: Thu, 25 Jul 2024 15:36:33 +0200
> 
> I've search about this issue and found the following link:
> https://old.reddit.com/r/openbsd/comments/1atanzd/color_emoji_not_shown/
> 
> When I apply the recipe describe by sthen@ here, I can make color emoji
> to work in Emacs (and probably other applications).  Therefore, I
> propose that we add the following patch to etc/PROBLEMS.  WDYT?

Thanks, see some comments below.

> +** On OpenBSD, color Emoji are not supported.
> +
> +The system's FreeType library is not built with libpng support, so it
> +can't display compressed colour emoji.  This is due to the fact that, on
> +OpenBSD, libpng is provided through ports and that a base component
> +cannot depend on that.

First, we use US English spelling, so it should be "color", not
"colour".

More importantly, I don't think I understand the user-level meaning of
this.  You say "compressed color Emoji", but what does that mean in
practice?  Does it mean no font which supports color Emoji display
will ever work on OpenBSD unless the FreeType library is rebuilt with
PNG support?  If so (but then why say "compressed" above?), I think we
should say so and include a bit more details about rebuilding FreeType
on OpenBSD, like that Reddit discussion mentions.  OTOH, if some Emoji
fonts can be used on OpenBSD, we should say that as well, and perhaps
mention those fonts, if they are free.

IOW, PROBLEMS is supposed to describe the problems and their solutions
or workarounds in user-understandable terms, because that file is for
Emacs users, not for Emacs developers.

bug#72268: 31.0.50; Color emoji rendering

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> IOW, PROBLEMS is supposed to describe the problems and their solutions
> or workarounds in user-understandable terms, because that file is for
> Emacs users, not for Emacs developers.

I'd recommend moving the remarks that might be useful for developers to
the commit message, where we can easily find it later.  Then you can
also afford going into even more detail, should that makes sense.

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

[...]

>> +** On OpenBSD, color Emoji are not supported.
>> +
>> +The system's FreeType library is not built with libpng support, so it
>> +can't display compressed colour emoji.  This is due to the fact that, on
>> +OpenBSD, libpng is provided through ports and that a base component
>> +cannot depend on that.
>
> First, we use US English spelling, so it should be "color", not
> "colour".

Ok, I'll change this one.

> More importantly, I don't think I understand the user-level meaning of
> this.  You say "compressed color Emoji", but what does that mean in
> practice?  Does it mean no font which supports color Emoji display
> will ever work on OpenBSD unless the FreeType library is rebuilt with
> PNG support?

I'm not sure myself.  "compressed color Emoji" is a copy-paste I made
from sthen@ own words.  Maybe it is refering to the PNG compression.

>If so (but then why say "compressed" above?), I think we should say so
>and include a bit more details about rebuilding FreeType on OpenBSD,
>like that Reddit discussion mentions.  OTOH, if some Emoji fonts can be
>used on OpenBSD, we should say that as well, and perhaps mention those
>fonts, if they are free.
>
> IOW, PROBLEMS is supposed to describe the problems and their solutions
> or workarounds in user-understandable terms, because that file is for
> Emacs users, not for Emacs developers.

I am wary about adding the described workaround because it modifies the
system's FreeType library for all applications.  And it does so by
relying on a ports (think a 3rd party package) of libpng.  I don't know
what would happen should someone remove the libpng package after having
applied this workaround.  Also, as explained in this recipe, it will be
gone after each system upgrade.

My idea was more to record this limitation into "etc/PROBLEMS" for
future reference.
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: rpluim@gmail.com,  luangruo@yahoo.com,  72268@debbugs.gnu.org
> Date: Thu, 25 Jul 2024 18:15:46 +0200
> 
> > More importantly, I don't think I understand the user-level meaning of
> > this.  You say "compressed color Emoji", but what does that mean in
> > practice?  Does it mean no font which supports color Emoji display
> > will ever work on OpenBSD unless the FreeType library is rebuilt with
> > PNG support?
> 
> I'm not sure myself.  "compressed color Emoji" is a copy-paste I made
> from sthen@ own words.  Maybe it is refering to the PNG compression.

Since it says "compressed color Emoji", it probably refers to the
font.  If we cannot establish whether there are any color Emoji fonts
that don't need "compressed" PNG, we should probably not mention the
"compressed" part at all, but just say that one needs FreeType with
PNG support to use any color Emoji fonts.

> >If so (but then why say "compressed" above?), I think we should say so
> >and include a bit more details about rebuilding FreeType on OpenBSD,
> >like that Reddit discussion mentions.  OTOH, if some Emoji fonts can be
> >used on OpenBSD, we should say that as well, and perhaps mention those
> >fonts, if they are free.
> >
> > IOW, PROBLEMS is supposed to describe the problems and their solutions
> > or workarounds in user-understandable terms, because that file is for
> > Emacs users, not for Emacs developers.
> 
> I am wary about adding the described workaround because it modifies the
> system's FreeType library for all applications.  And it does so by
> relying on a ports (think a 3rd party package) of libpng.  I don't know
> what would happen should someone remove the libpng package after having
> applied this workaround.  Also, as explained in this recipe, it will be
> gone after each system upgrade.

We can include the caveats in the text, so that users could make
informed decisions for themselves.

> My idea was more to record this limitation into "etc/PROBLEMS" for
> future reference.

That's not what PROBLEMS is for.  If a problem has a solution or a
workaround, we should describe them.  Maybe it's just me, but I see
rebuilding FreeType as a no-brainer, so if I were in your shoes, I
would not have hesitated to rebuild it.  I'm quite sure there are
others who would think the same.

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Manuel Giraud <manuel@ledu-giraud.fr>
>> Cc: rpluim@gmail.com,  luangruo@yahoo.com,  72268@debbugs.gnu.org
>> Date: Thu, 25 Jul 2024 18:15:46 +0200
>> 
>> > More importantly, I don't think I understand the user-level meaning of
>> > this.  You say "compressed color Emoji", but what does that mean in
>> > practice?  Does it mean no font which supports color Emoji display
>> > will ever work on OpenBSD unless the FreeType library is rebuilt with
>> > PNG support?
>> 
>> I'm not sure myself.  "compressed color Emoji" is a copy-paste I made
>> from sthen@ own words.  Maybe it is refering to the PNG compression.
>
> Since it says "compressed color Emoji", it probably refers to the
> font.  If we cannot establish whether there are any color Emoji fonts
> that don't need "compressed" PNG, we should probably not mention the
> "compressed" part at all, but just say that one needs FreeType with
> PNG support to use any color Emoji fonts.

Ok, I'll remove the "compressed" then.

[...]

>> I am wary about adding the described workaround because it modifies the
>> system's FreeType library for all applications.  And it does so by
>> relying on a ports (think a 3rd party package) of libpng.  I don't know
>> what would happen should someone remove the libpng package after having
>> applied this workaround.  Also, as explained in this recipe, it will be
>> gone after each system upgrade.
>
> We can include the caveats in the text, so that users could make
> informed decisions for themselves.
>
>> My idea was more to record this limitation into "etc/PROBLEMS" for
>> future reference.
>
> That's not what PROBLEMS is for.  If a problem has a solution or a
> workaround, we should describe them.  Maybe it's just me, but I see
> rebuilding FreeType as a no-brainer, so if I were in your shoes, I
> would not have hesitated to rebuild it.  I'm quite sure there are
> others who would think the same.

Yes I understand.  I could try to rephrase a bit what's on Reddit but I
don't think we should go into the details of how to build a library of
Xenocara (OpenBSD Xorg modules compilation): there is the release(8)
manpage for this.
-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: rpluim@gmail.com,  luangruo@yahoo.com,  72268@debbugs.gnu.org
> Date: Thu, 25 Jul 2024 22:07:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's not what PROBLEMS is for.  If a problem has a solution or a
> > workaround, we should describe them.  Maybe it's just me, but I see
> > rebuilding FreeType as a no-brainer, so if I were in your shoes, I
> > would not have hesitated to rebuild it.  I'm quite sure there are
> > others who would think the same.
> 
> Yes I understand.  I could try to rephrase a bit what's on Reddit but I
> don't think we should go into the details of how to build a library of
> Xenocara (OpenBSD Xorg modules compilation): there is the release(8)
> manpage for this.

Indeed, we don't need to describe all the details there.  We just need
to say that display of color Emoji needs the FreeType library with PNG
support, and if such a FreeType library is not available, users could
consider rebuilding it with PNG support on their system.

bug#72268: 31.0.50; Color emoji rendering

[Manuel Giraud via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Eli Zaretskii <eliz@gnu.org> writes:

[...]

> Indeed, we don't need to describe all the details there.  We just need
> to say that display of color Emoji needs the FreeType library with PNG
> support, and if such a FreeType library is not available, users could
> consider rebuilding it with PNG support on their system.

What do you think of this?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-unsupported-color-Emoji-on-OpenBSD.patch --]
[-- Type: text/x-patch, Size: 1742 bytes --]

From f2b542d9efdee4908e5a99a1a62adf610048b4b5 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel@ledu-giraud.fr>
Date: Thu, 25 Jul 2024 13:57:59 +0200
Subject: [PATCH] Document unsupported color Emoji on OpenBSD

Bug#72268

* etc/PROBLEMS (Runtime problems related to font handling):
Document unsupported color Emoji on OpenBSD.
---
 etc/PROBLEMS | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index f8fb9f90c0b..939005780a8 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -1274,6 +1274,27 @@ Emacs will select some other font instead.
 The only workaround is not to choose such font variants as the default
 font when running Emacs on MS-Windows.
 
+** On OpenBSD, color Emoji are not supported by default.
+
+The system's FreeType library is not built with libpng support, so it
+can't display color emoji.  This is due to the fact that, on OpenBSD,
+libpng is provided through ports and that a base component cannot depend
+on that.
+
+However, you can add support for PNG in the system's FreeType library by
+following those steps:
+	1. Install the 'png' package.
+	2. Read the release(8) man page for how to get Xenocara sources.
+	3. Patch the file
+	   "/usr/xenocara/lib/freetype/include/freetype/config/ftoption.h"
+	   by uncommenting the "#define FT_CONFIG_OPTION_USE_PNG" line.
+	4. Patch the file "/usr/xenocara/lib/freetype/Makefile" by
+	   appending "-L/usr/local/lib -lpng" to LDADD and appending
+	   "-I/usr/local/include" to CPPFLAGS.
+	5. Build and install Xenocara (also, see release(8)).
+
+Note that this support will be gone after each OpenBSD's system upgrade.
+
 * Internationalization problems
 
 ** M-{ does not work on a Spanish PC keyboard.
-- 
2.45.2


[-- Attachment #3: Type: text/plain, Size: 18 bytes --]

-- 
Manuel Giraud

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> From: Manuel Giraud <manuel@ledu-giraud.fr>
> Cc: rpluim@gmail.com,  luangruo@yahoo.com,  72268@debbugs.gnu.org
> Date: Fri, 26 Jul 2024 11:25:43 +0200
> 
> > Indeed, we don't need to describe all the details there.  We just need
> > to say that display of color Emoji needs the FreeType library with PNG
> > support, and if such a FreeType library is not available, users could
> > consider rebuilding it with PNG support on their system.
> 
> What do you think of this?

LGTM, thanks.

bug#72268: 31.0.50; Color emoji rendering

[Eli Zaretskii]

> Cc: luangruo@yahoo.com, rpluim@gmail.com, 72268@debbugs.gnu.org
> Date: Fri, 26 Jul 2024 13:41:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Manuel Giraud <manuel@ledu-giraud.fr>
> > Cc: rpluim@gmail.com,  luangruo@yahoo.com,  72268@debbugs.gnu.org
> > Date: Fri, 26 Jul 2024 11:25:43 +0200
> > 
> > > Indeed, we don't need to describe all the details there.  We just need
> > > to say that display of color Emoji needs the FreeType library with PNG
> > > support, and if such a FreeType library is not available, users could
> > > consider rebuilding it with PNG support on their system.
> > 
> > What do you think of this?
> 
> LGTM, thanks.

Now installed on the emacs-30 branch, and closing the bug.