bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

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



On OSX, this pretest release breaks render of some unicode chars.

;;; 😀😂
(set-frame-font "Monaco:pixelsize=16")
(set-fontset-font
(frame-parameter nil 'font)
'symbol (font-spec :family "Apple Color Emoji") nil 'prepend)

there should be two symbols in the first line of above snippets if
rendered correctly.

BTW, the last pretest does not have such issue. the version of last
pretest is:

GNU Emacs 25.0.92.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603)) of 2016-03-03

Thanks.




In GNU Emacs 25.0.93.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603))
of 2016-04-23 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: zh_CN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Mark set [2 times]
Undo!
nil [2 times]
Mark set [4 times]
Making completion list...
Quit

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
china-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic 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 charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 196958 18232)
(symbols 48 19782 0)
(miscs 40 57 225)
(strings 32 15231 7957)
(string-bytes 1 439568)
(vectors 16 36974)
(vector-slots 8 1147710 127702)
(floats 8 159 267)
(intervals 56 249 20)
(buffers 976 12))

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> From: Peter Wang <ptr.wang@gmail.com>
> Date: Mon, 25 Apr 2016 01:40:59 +0800
> 
> On OSX, this pretest release breaks render of some unicode chars.
> 
> ;;; 😀😂
> (set-frame-font "Monaco:pixelsize=16")
> (set-fontset-font
> (frame-parameter nil 'font)
> 'symbol (font-spec :family "Apple Color Emoji") nil 'prepend)
> 
> there should be two symbols in the first line of above snippets if
> rendered correctly.
> 
> BTW, the last pretest does not have such issue. the version of last
> pretest is:
> 
> GNU Emacs 25.0.92.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603)) of
> 2016-03-03

Isn't this a consequence of this commit:

  commit 9344612d3cd164317170b6189ec43175757e4231
  Author: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
  Date:   Tue Apr 12 08:26:51 2016 +0900

      Disable multicolor fonts on OS X since they are not supported on free system

      * src/macfont.m (macfont_list): Don't use color bitmap fonts.

If you revert it, does the problem go away?  If not, can you please
bisect the emacs-25 branch between 25.0.92 and now, and see which
commit caused this?

Thanks.

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Peter Wang <ptr.wang@gmail.com>
>> Date: Mon, 25 Apr 2016 01:40:59 +0800
>> 
>> On OSX, this pretest release breaks render of some unicode chars.
>> 
>> ;;; 😀😂
>> (set-frame-font "Monaco:pixelsize=16")
>> (set-fontset-font
>> (frame-parameter nil 'font)
>> 'symbol (font-spec :family "Apple Color Emoji") nil 'prepend)
>> 
>> there should be two symbols in the first line of above snippets if
>> rendered correctly.
>> 
>> BTW, the last pretest does not have such issue. the version of last
>> pretest is:
>> 
>> GNU Emacs 25.0.92.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603)) of
>> 2016-03-03
>
> Isn't this a consequence of this commit:
>
>   commit 9344612d3cd164317170b6189ec43175757e4231
>   Author: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>   Date:   Tue Apr 12 08:26:51 2016 +0900
>
>       Disable multicolor fonts on OS X since they are not supported on free system
>
>       * src/macfont.m (macfont_list): Don't use color bitmap fonts.
>
> If you revert it, does the problem go away?  If not, can you please
> bisect the emacs-25 branch between 25.0.92 and now, and see which
> commit caused this?
>
> Thanks.

I tried to revert this commit (one line of code) on head
(e6d6a99455183bca5074b7601ad11d424da6442e) and rebuild it. Now the issue
goes away.

If I understand correctly, this part of code is OSX specific, how is it
related to other free system? Could you elaborate more on it, Thanks!

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 25 Apr 2016 04:59:17 +0800, Peter Wang <ptr.wang@gmail.com> said:

> I tried to revert this commit (one line of code) on head
> (e6d6a99455183bca5074b7601ad11d424da6442e) and rebuild it. Now the
> issue goes away.

> If I understand correctly, this part of code is OSX specific, how is
> it related to other free system? Could you elaborate more on it,
> Thanks!

The code is specific to OS X, but the general multicolor font feature
is not.  The related thread starts from:

  http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00713.html

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> Date: Mon, 25 Apr 2016 09:37:46 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: Eli Zaretskii <eliz@gnu.org>,
> 	23362@debbugs.gnu.org
> 
> >>>>> On Mon, 25 Apr 2016 04:59:17 +0800, Peter Wang <ptr.wang@gmail.com> said:
> 
> > I tried to revert this commit (one line of code) on head
> > (e6d6a99455183bca5074b7601ad11d424da6442e) and rebuild it. Now the
> > issue goes away.
> 
> > If I understand correctly, this part of code is OSX specific, how is
> > it related to other free system? Could you elaborate more on it,
> > Thanks!
> 
> The code is specific to OS X, but the general multicolor font feature
> is not.  The related thread starts from:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00713.html

Could you perhaps write a short entry about the consequences of this
in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
such complaints in the future, so it would be nice to have a place to
point people at.

Thanks.

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 25 Apr 2016 09:01:11 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> The code is specific to OS X, but the general multicolor font
>> feature is not.  The related thread starts from:
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00713.html

> Could you perhaps write a short entry about the consequences of this
> in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
> such complaints in the future, so it would be nice to have a place
> to point people at.

I've just added a NEWS entry that explains why it was included and
then disabled.

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

Thanks for the clarification.

IIUC, this feature won't go in release 25.1, right?

On Mon, 25 Apr 2016, YAMAMOTO Mitsuharu wrote:

>>>>>> On Mon, 25 Apr 2016 09:01:11 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>>> The code is specific to OS X, but the general multicolor font
>>> feature is not.  The related thread starts from:
>>>
>>> http://lists.gnu.org/archive/html/emacs-devel/2015-12/msg00713.html
>
>> Could you perhaps write a short entry about the consequences of this
>> in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
>> such complaints in the future, so it would be nice to have a place
>> to point people at.
>
> I've just added a NEWS entry that explains why it was included and
> then disabled.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> Date: Mon, 25 Apr 2016 17:28:23 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: ptr.wang@gmail.com,
> 	23362@debbugs.gnu.org
> 
> > Could you perhaps write a short entry about the consequences of this
> > in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
> > such complaints in the future, so it would be nice to have a place
> > to point people at.
> 
> I've just added a NEWS entry that explains why it was included and
> then disabled.

Thanks.  However, the OP seems to imply that the Emoji symbols are
rendered incorrectly, or not displayed at all, when multicolor fonts
are used, not just that the colors are not shown.  If that is true (is
it?), I'd suggest to have in NEWS a workaround (use a different
font?), not just a statement of the fact that we don't support these
fonts.

Thanks.

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

Peter Wang <ptr.wang@gmail.com> writes:

> Thanks for the clarification.
>
> IIUC, this feature won't go in release 25.1, right?

Most likely.

BTW, proper color emoji support does not mean just supporting multicolor
font display (see http://unicode.org/reports/tr51/).  For example,

* emoji variation sequence
☝︎
☝️

* emoji modifier sequence
✊ ✊🏻✊🏼✊🏽✊🏾✊🏿

* emoji flag sequence
🇯🇵

* emoji zwj sequence
👨‍👩‍👧‍👦

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1001 bytes --]

Here is a screenshot showing the difference.

On Mon, Apr 25, 2016 at 4:59 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Mon, 25 Apr 2016 17:28:23 +0900
> > From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> > Cc: ptr.wang@gmail.com,
> >       23362@debbugs.gnu.org
> >
> > > Could you perhaps write a short entry about the consequences of this
> > > in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
> > > such complaints in the future, so it would be nice to have a place
> > > to point people at.
> >
> > I've just added a NEWS entry that explains why it was included and
> > then disabled.
>
> Thanks.  However, the OP seems to imply that the Emoji symbols are
> rendered incorrectly, or not displayed at all, when multicolor fonts
> are used, not just that the colors are not shown.  If that is true (is
> it?), I'd suggest to have in NEWS a workaround (use a different
> font?), not just a statement of the fact that we don't support these
> fonts.
>
> Thanks.
>

[-- Attachment #1.2: Type: text/html, Size: 1580 bytes --]

[-- Attachment #2: emacs_unicode_display.png --]
[-- Type: image/png, Size: 101456 bytes --]

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 25 Apr 2016 11:59:18 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> Date: Mon, 25 Apr 2016 17:28:23 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Cc: ptr.wang@gmail.com,
>> 23362@debbugs.gnu.org
>> 
>> > Could you perhaps write a short entry about the consequences of this
>> > in NEWS, and perhaps also in PROBLEMS?  I guess we will be receiving
>> > such complaints in the future, so it would be nice to have a place
>> > to point people at.
>> 
>> I've just added a NEWS entry that explains why it was included and
>> then disabled.

> Thanks.  However, the OP seems to imply that the Emoji symbols are
> rendered incorrectly, or not displayed at all, when multicolor fonts
> are used, not just that the colors are not shown.  If that is true (is
> it?), I'd suggest to have in NEWS a workaround (use a different
> font?), not just a statement of the fact that we don't support these
> fonts.

With the current 25.0.93, an attempt to display emoji (where only
Apple Color Emoji provides its glyph) results in the same appearance
(i.e., not displaying at all) regardless of the explicit font setting
given by the OP.  Even the default setting in 24.5 looks the same.

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> Date: Mon, 25 Apr 2016 18:40:16 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: ptr.wang@gmail.com,
> 	23362@debbugs.gnu.org
> 
> > Thanks.  However, the OP seems to imply that the Emoji symbols are
> > rendered incorrectly, or not displayed at all, when multicolor fonts
> > are used, not just that the colors are not shown.  If that is true (is
> > it?), I'd suggest to have in NEWS a workaround (use a different
> > font?), not just a statement of the fact that we don't support these
> > fonts.
> 
> With the current 25.0.93, an attempt to display emoji (where only
> Apple Color Emoji provides its glyph) results in the same appearance
> (i.e., not displaying at all) regardless of the explicit font setting
> given by the OP.

But the original report in this bug, displayed on MS-Windows using the
Symbola font, shows the two emoji symbols for me, albeit devoid of any
color.  So if on OS X they don't display at all, that's something that
should be fixable by selecting some other font, such as Symbola, which
has glyphs for these symbols, no?  Or am I missing something here?

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 25 Apr 2016 12:59:07 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> With the current 25.0.93, an attempt to display emoji (where only
>> Apple Color Emoji provides its glyph) results in the same
>> appearance (i.e., not displaying at all) regardless of the explicit
>> font setting given by the OP.

> But the original report in this bug, displayed on MS-Windows using
> the Symbola font, shows the two emoji symbols for me, albeit devoid
> of any color.  So if on OS X they don't display at all, that's
> something that should be fixable by selecting some other font, such
> as Symbola, which has glyphs for these symbols, no?  Or am I missing
> something here?

To be more precise, "disabling multicolor font" means it effectively
excludes multicolor fonts from available ones.  It does not disable
font *display* code actually, but that part is now effectively dead
because we can no longer select multicolor fonts.

The change I made does not prevent emoji from being displayed with
other non-multicolor fonts.  Moreover, the appearance with the default
setting is the same between 24.5 and 25.0.93.  So I don't think we
need to provide a workaround.

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> Date: Mon, 25 Apr 2016 19:07:45 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
> 	ptr.wang@gmail.com,
> 	23362@debbugs.gnu.org
> 
> The change I made does not prevent emoji from being displayed with
> other non-multicolor fonts.  Moreover, the appearance with the default
> setting is the same between 24.5 and 25.0.93.  So I don't think we
> need to provide a workaround.

Thanks, that's good to know.

However, there's something I still don't understand: how come the OP
doesn't see any symbols at all (see the screenshots he provided)?
IOW, if the default setting works fine, is there some non-default
setting we should be telling users to avoid, in order to have these
symbols displayed (albeit without colors)?

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 25 Apr 2016 13:19:51 +0300, Eli Zaretskii <eliz@gnu.org> said:

>> The change I made does not prevent emoji from being displayed with
>> other non-multicolor fonts.  Moreover, the appearance with the
>> default setting is the same between 24.5 and 25.0.93.  So I don't
>> think we need to provide a workaround.

> Thanks, that's good to know.

> However, there's something I still don't understand: how come the OP
> doesn't see any symbols at all (see the screenshots he provided)?

Because the OS-bundled fonts other than Apple Color Emoji do not
contain glyphs for U+1F600 or U+1F602.  I.e., font is not available
for these characters.

> IOW, if the default setting works fine, is there some non-default
> setting we should be telling users to avoid, in order to have these
> symbols displayed (albeit without colors)?

Installing some third-party monochrome emoji fonts?  Unfortunately I'm
not familiar with such fonts.

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

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> Date: Mon, 25 Apr 2016 19:33:33 +0900
> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Cc: ptr.wang@gmail.com,
>     23362@debbugs.gnu.org
>
> > IOW, if the default setting works fine, is there some non-default
> > setting we should be telling users to avoid, in order to have
> > these
> > symbols displayed (albeit without colors)?
>
> Installing some third-party monochrome emoji fonts?  Unfortunately
> I'm
> not familiar with such fonts.

Symbola should do, and the default fontset already assigns the emoji
block to it.  Are there any issues with Symbola on OS X?

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1066 bytes --]

The configuration In that screenshot is the only one EVAL-ed after  `Emacs -q -Q’

Maybe the non-default setting you mentioned is this configuration.


> 在 2016年4月25日，18:19，Eli Zaretskii <eliz@gnu.org> 写道：
> 
>> Date: Mon, 25 Apr 2016 19:07:45 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
>> 	ptr.wang@gmail.com,
>> 	23362@debbugs.gnu.org
>> 
>> The change I made does not prevent emoji from being displayed with
>> other non-multicolor fonts.  Moreover, the appearance with the default
>> setting is the same between 24.5 and 25.0.93.  So I don't think we
>> need to provide a workaround.
> 
> Thanks, that's good to know.
> 
> However, there's something I still don't understand: how come the OP
> doesn't see any symbols at all (see the screenshots he provided)?
> IOW, if the default setting works fine, is there some non-default
> setting we should be telling users to avoid, in order to have these
> symbols displayed (albeit without colors)?


[-- Attachment #1.2: Type: text/html, Size: 2159 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1088 bytes --]

I have tried the Symbola font from here:

http://users.teilar.gr/~g1951d/ <http://users.teilar.gr/~g1951d/>

starting emacs with Emacs -q -Q, it does not display the unicode char at all.

tried apply configuration:

(set-frame-font "Monaco:pixelsize=16")
(set-fontset-font
 (frame-parameter nil 'font) 'symbol (font-spec :family "Symbola") nil 'prepend)

The same, it does not work.



> 在 2016年4月25日，19:00，Eli Zaretskii <eliz@gnu.org> 写道：
> 
>> Date: Mon, 25 Apr 2016 19:33:33 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Cc: ptr.wang@gmail.com,
>>    23362@debbugs.gnu.org
>> 
>>> IOW, if the default setting works fine, is there some non-default
>>> setting we should be telling users to avoid, in order to have
>>> these
>>> symbols displayed (albeit without colors)?
>> 
>> Installing some third-party monochrome emoji fonts?  Unfortunately
>> I'm
>> not familiar with such fonts.
> 
> Symbola should do, and the default fontset already assigns the emoji
> block to it.  Are there any issues with Symbola on OS X?


[-- Attachment #1.2: Type: text/html, Size: 2342 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1059 bytes --]

I removed the Symbola font and re-installed it.

Now it works as expected in this pretest release:

The symbol is displayed, without color,

C-u c-x =  shows that it is using the Symbola font.

Sorry about the trouble and thanks again.




> 在 2016年4月25日，19:00，Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> 写道：
> 
>> Date: Mon, 25 Apr 2016 19:33:33 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp <mailto:mituharu@math.s.chiba-u.ac.jp>>
>> Cc: ptr.wang@gmail.com <mailto:ptr.wang@gmail.com>,
>>    23362@debbugs.gnu.org <mailto:23362@debbugs.gnu.org>
>> 
>>> IOW, if the default setting works fine, is there some non-default
>>> setting we should be telling users to avoid, in order to have
>>> these
>>> symbols displayed (albeit without colors)?
>> 
>> Installing some third-party monochrome emoji fonts?  Unfortunately
>> I'm
>> not familiar with such fonts.
> 
> Symbola should do, and the default fontset already assigns the emoji
> block to it.  Are there any issues with Symbola on OS X?


[-- Attachment #1.2: Type: text/html, Size: 2171 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Peter Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1059 bytes --]

I removed the Symbola font and re-installed it.

Now it works as expected in this pretest release:

The symbol is displayed, without color,

C-u c-x =  shows that it is using the Symbola font.

Sorry about the trouble and thanks again.




> 在 2016年4月25日，19:00，Eli Zaretskii <eliz@gnu.org <mailto:eliz@gnu.org>> 写道：
> 
>> Date: Mon, 25 Apr 2016 19:33:33 +0900
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp <mailto:mituharu@math.s.chiba-u.ac.jp>>
>> Cc: ptr.wang@gmail.com <mailto:ptr.wang@gmail.com>,
>>    23362@debbugs.gnu.org <mailto:23362@debbugs.gnu.org>
>> 
>>> IOW, if the default setting works fine, is there some non-default
>>> setting we should be telling users to avoid, in order to have
>>> these
>>> symbols displayed (albeit without colors)?
>> 
>> Installing some third-party monochrome emoji fonts?  Unfortunately
>> I'm
>> not familiar with such fonts.
> 
> Symbola should do, and the default fontset already assigns the emoji
> block to it.  Are there any issues with Symbola on OS X?


[-- Attachment #1.2: Type: text/html, Size: 2238 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Lars Magne Ingebrigtsen]

Peter Wang <ptr.wang@gmail.com> writes:

> I removed the Symbola font and re-installed it. 
>
> Now it works as expected in this pretest release:

Ok; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23362: 25.0.93; Unicode chars (such as 0x1F600) are not rendered correctly

[Eli Zaretskii]

> From: Peter Wang <ptr.wang@gmail.com>
> Date: Mon, 25 Apr 2016 19:58:47 +0800
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
>  23362@debbugs.gnu.org
> 
> I removed the Symbola font and re-installed it. 
> Now it works as expected in this pretest release:
> The symbol is displayed, without color, 
> C-u c-x = shows that it is using the Symbola font.

Thanks, I added this workaround to NEWS.