GNU bug report logs -
#41747
27.0.91; Add default fontset setup for "Symbols and Pictographs Extended-A"
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 41747 in the body.
You can then email your comments to 41747 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Sun, 07 Jun 2020 13:44:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 07 Jun 2020 13:44:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
IIUC, "Symbols and Pictographs Extended-A"[1][2] is a new Unicode block
that showed up in version 12.0 and extends the "Supplemental Symbols and
Pictographs" block.
Since we use Symbola for the latter, I figure it wouldn't hurt to also
use this font for the former? AFAICT Symbola covers the whole block[3].
Here is a patch to that effect:
[0001-Use-Symbola-to-cover-Symbols-and-Pictographs-Extende.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
(Will followup with an updated patch as soon as I get a bug number.)
FWIW, I found out about this block after
- hearing that Unicode 13.0 included new emojis,
- waiting for an updated version of Symbola to be released[4],
- trying to insert some of the new emojis in Emacs,
- noticing that some of them (e.g. 🩴 U+1FA74, 🪗 U+1FA97, 🫕 U+1FAD5)
are not displayed (C-u C-x = says "display: no font available",
despite Symbola covering them).
- going straight to fontset.el to understand why Symbola wasn't picked
automatically.
Of course, users can work around this with:
(set-fontset-font t '(#x1FA70 . #x1FAFF) "Symbola" nil 'append)
Thank you for your time.
[1] https://www.unicode.org/charts/PDF/Unicode-13.0/U130-1FA70.pdf
[2] https://en.wikipedia.org/wiki/Symbols_and_Pictographs_Extended-A
[3] https://dn-works.com/wp-content/uploads/2020/UFAS-Docs/Symbola.pdf
p.14
[4] https://dn-works.com/ufas/
In GNU Emacs 28.0.50 (build 32, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
of 2020-05-30 built on my-little-tumbleweed
Repository revision: 780f674a82a90c4e3e32583059b498bfa57e4a06
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: openSUSE Tumbleweed
Configured using:
'configure --with-xwidgets --with-cairo'
Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP
Important settings:
value of $LC_CTYPE: en_US.UTF-8
value of $LC_TIME: en_GB.UTF-8
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Sun, 07 Jun 2020 13:48:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
> (Will followup with an updated patch as soon as I get a bug number.)
See attached.
[0001-Use-Symbola-to-cover-Symbols-and-Pictographs-Extende.patch (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Sun, 07 Jun 2020 14:40:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Sun, 07 Jun 2020 15:43:40 +0200
>
> Since we use Symbola for the latter, I figure it wouldn't hurt to also
> use this font for the former? AFAICT Symbola covers the whole block[3].
Not the Symbola I have here. Which version of Symbola do you have
that supports that block, and is that version distributed under a free
license?
Reply sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
You have taken responsibility.
(Sun, 07 Jun 2020 15:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
:
bug acknowledged by developer.
(Sun, 07 Jun 2020 15:23:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 41747-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
>> Date: Sun, 07 Jun 2020 15:43:40 +0200
>>
>> Since we use Symbola for the latter, I figure it wouldn't hurt to also
>> use this font for the former? AFAICT Symbola covers the whole block[3].
>
> Not the Symbola I have here. Which version of Symbola do you have
> that supports that block, and is that version distributed under a free
> license?
As I referenced, the version available on <https://dn-works.com/ufas/>.
Unfortunately, I just realized that newer versions no longer come under
a free license[1][2][3][4]. That definitely took me by surprise.
*sigh* Closing then. Sorry for the noise.
[1] https://dn-works.com/wp-content/uploads/2020/UFAS-Docs/License.pdf
[2] https://github.com/NixOS/nixpkgs/pull/79679
[3] https://bugs.archlinux.org/task/58886
[4] https://lists.fedoraproject.org/archives/list/devel <at> lists.fedoraproject.org/thread/EC6I35ILFICKY5W5XTHYJC6UH36B2UQS/
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Mon, 08 Jun 2020 14:37:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: 41747-done <at> debbugs.gnu.org
> Date: Sun, 07 Jun 2020 17:22:36 +0200
>
> > Not the Symbola I have here. Which version of Symbola do you have
> > that supports that block, and is that version distributed under a free
> > license?
>
> As I referenced, the version available on <https://dn-works.com/ufas/>.
>
> Unfortunately, I just realized that newer versions no longer come under
> a free license[1][2][3][4]. That definitely took me by surprise.
>
> *sigh* Closing then. Sorry for the noise.
Maybe you could find a free font that covers this block, then we could
use that instead of Symbola.
TIA
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Mon, 08 Jun 2020 21:00:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 41747 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Maybe you could find a free font that covers this block, then we could
> use that instead of Symbola.
I've looked, but no clear winner has emerged.
Of course, GNU Unifont covers this block, though I had not realized this
at first because one has to install Unifont Upper, which I had to grab
from unifoundry.com because my distro does not package it AFAICT. Once
that's installed, emacs -Q seems to pick it up automatically, so the
situation is not as critical as I thought.
Then there are color fonts dedicated to emoji. If we start using such a
font for the default fontset setup, it would probably make sense to
assign it to more blocks than just "Symbols and Pictographs Extended-A",
otherwise people will wonder why some emoji show up with a color font
while others don't.
Finding all emoji that should be displayed with a color font sounds like
a whole other issue which probably deserves its own bug report. I
imagine we'd need to scrape Unicode's emoji-data.txt to figure which
characters have Emoji_Presentation set; IIUC the subject has already
been broached in bug#39799.
As to which emoji font we could pick…
- Noto Color Emoji (SIL Open Font License) seems the most ubiquitous
AFAICT (packaged in e.g. Debian, OpenSUSE, Fedora; a .ttf file is
available in the developer repository). It doesn't cover Unicode 13
yet but that shouldn't take long.
- Twemoji (CC-BY) covers Unicode 13, unfortunately the procedure to get
a .ttf is a bit… involved. IIUC Fedora re-uses Noto's machinery to
generate a TrueType font from SVG assets[1]. I haven't seen many
distributions packaging it yet.
- OpenMoji (CC-BY-SA) is making progress on Unicode 13 coverage[2]; it
also has a "black" (non-colored) variant, which means we could use it
for blocks not covered by the older Symbola and it wouldn't look out
of place. In fact the "color" variant only shows up as colored with
Firefox, for some reason[3]. There are .ttf files in the developer
repository, but they don't seem to be packaged by many distros yet
(it's in OpenSUSE, it'll get into Fedora Soonish™[4]).
There are probably other candidates. For the purpose of this bug report
however, GNU Unifont is the only free, readily available, and non-color
option I have found for "Symbols and Pictographs Extended-A".
Since Emacs already uses that… SNAFU, I'd conclude.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1514274
[2] https://github.com/hfg-gmuend/openmoji/issues/124
[3] https://github.com/hfg-gmuend/openmoji/issues/93
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1803059
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 02:36:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
> > Unfortunately, I just realized that newer versions no longer come under
> > a free license[1][2][3][4]. That definitely took me by surprise.
This sounds like a possibly important issue, though perhaps mostly
independent of Emacs. Would someone who knows the Symbols situation
well please offer to explain this to me?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 02:39:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
> There are probably other candidates. For the purpose of this bug report
> however, GNU Unifont is the only free, readily available, and non-color
> option I have found for "Symbols and Pictographs Extended-A".
> Since Emacs already uses that… SNAFU, I'd conclude.
Can someone explain to me why this constitutes failure, rather than success?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 09:29:01 GMT)
Full text and
rfc822 format available.
Message #31 received at submit <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> This sounds like a possibly important issue, though perhaps mostly
> independent of Emacs. Would someone who knows the Symbols situation
> well please offer to explain this to me?
Here's my attempt at a summary; corrections welcome:
- Up to 2018, the Unicode Fonts for Ancient Scripts (UFAS) project
released its fonts under terms that suggested a free license[1]:
- One of these fonts, Symbola, has an exhaustive coverage of Unicode
"symbol" characters, so exhaustive that we use it in our default
fontset for various "symbol subgroups"[2].
- In 2018, the license for UFAS has changed to the document I referenced
in my earlier message[3].
- Most GNU/Linux distributions reached the same conclusion: the terms of
this new license does not allow redistribution under any way, shape or
form[4]. Therefore, these distros now only ship the last free-license
version of Symbola.
- New versions of Unicode have come and gone since then; they have
introduced new blocks and new characters (cf. the initial bug report).
- Newer versions of Symbola have followed like clockwork to cover the
latest "symbol" characters.
- Unfortunately, these new versions fall under the new, non-free
license. IIUC this makes them unsuitable for Emacs's default fontset.
Distro developers have reached out to the UFAS developer (as recently as
two months ago for Gentoo[4]; see also Fedora thread linked earlier),
but they could not convince him to switch back to a free license.
[1] The terms have changed over the years; see for example:
https://web.archive.org/web/20150316132421/http://users.teilar.gr/~g1951d/
> *in lieu of a licence* Fonts and documents in this site are not pieces
> of property or merchandise items; they carry no trademark, copyright,
> license or other market tags; they are free for any use. George Douros
https://web.archive.org/web/20180212144935/http://users.teilar.gr/~g1951d/
> In lieu of a licence; fonts and documents in this site are free for
> any use; George Douros
[2] M-x find-library RET fontset RET C-s Symbola
[3] https://dn-works.com/wp-content/uploads/2020/UFAS-Docs/License.pdf
[4] In my earlier message I linked to the relevant NixOS, Arch Linux and
Fedora threads; for good measure, here are Debian, Ubuntu and
Gentoo:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897047
https://bugs.launchpad.net/ubuntu/+source/ttf-ancient-fonts/+bug/1824065
https://www.mail-archive.com/gentoo-dev <at> lists.gentoo.org/msg88799.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 09:59:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 41747 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> [[[ 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. ]]]
>
> > There are probably other candidates. For the purpose of this bug report
> > however, GNU Unifont is the only free, readily available, and non-color
> > option I have found for "Symbols and Pictographs Extended-A".
>
> > Since Emacs already uses that… SNAFU, I'd conclude.
>
> Can someone explain to me why this constitutes failure, rather than success?
Mmm, maybe "SNAFU" is not the best term to convey my feelings about the
situation.
What I mean is that while the situation is not optimal ("Unifont Upper"
does not seem to be packaged by all distros; even then, its glyphs are
fairly low-res and sort of stick out next to other fonts ⇒ "all fouled
up"), Emacs's default fontset already covers the "Symbols and
Pictographs Extended-A" block, so no urgent action is needed (⇒
"situation normal").
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 14:21:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: 41747 <at> debbugs.gnu.org
> Date: Mon, 08 Jun 2020 22:59:32 +0200
>
> Of course, GNU Unifont covers this block, though I had not realized this
> at first because one has to install Unifont Upper, which I had to grab
> from unifoundry.com because my distro does not package it AFAICT. Once
> that's installed, emacs -Q seems to pick it up automatically, so the
> situation is not as critical as I thought.
GNU Unifont cannot be a real solution: it's too ugly.
> Then there are color fonts dedicated to emoji. If we start using such a
> font for the default fontset setup, it would probably make sense to
> assign it to more blocks than just "Symbols and Pictographs Extended-A",
> otherwise people will wonder why some emoji show up with a color font
> while others don't.
>
> Finding all emoji that should be displayed with a color font sounds like
> a whole other issue which probably deserves its own bug report. I
> imagine we'd need to scrape Unicode's emoji-data.txt to figure which
> characters have Emoji_Presentation set; IIUC the subject has already
> been broached in bug#39799.
Yes, but we don't need to do any serious research as to what emoji
should be supported by what font. Once we find a suitable free font,
we should simply mention it in preference (i.e. before) to the other
fonts that support the relevant blocks; then Emacs will automatically
DTRT given the available fonts.
> As to which emoji font we could pick…
Sounds like Noto Color Emoji is a good candidate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 14:37:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Cc: eliz <at> gnu.org, 41747 <at> debbugs.gnu.org
> Date: Mon, 08 Jun 2020 22:38:32 -0400
>
> > There are probably other candidates. For the purpose of this bug report
> > however, GNU Unifont is the only free, readily available, and non-color
> > option I have found for "Symbols and Pictographs Extended-A".
>
> > Since Emacs already uses that… SNAFU, I'd conclude.
>
> Can someone explain to me why this constitutes failure, rather than success?
GNU Unifont is an ugly font that isn't really meant to replace a
proper True Type font. It's meant to serve as the last fallback, so
that some glyph resembling the right one is displayed instead of a box
with a hex code or some similar stand-in.
Specifically, for displaying emoji it would be unimaginable, IMO, to
rely on Unifont as the solution.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Tue, 09 Jun 2020 14:43:01 GMT)
Full text and
rfc822 format available.
Message #43 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Date: Tue, 09 Jun 2020 11:27:49 +0200
>
> Richard Stallman <rms <at> gnu.org> writes:
>
> > This sounds like a possibly important issue, though perhaps mostly
> > independent of Emacs. Would someone who knows the Symbols situation
> > well please offer to explain this to me?
>
> Here's my attempt at a summary; corrections welcome:
AFAIK, this is correct: latest Symbola versions use a non-free license
(free only for personal and non-commercial use), so GNU/Linux distros
install old versions which are free.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 00:54:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
> Specifically, for displaying emoji it would be unimaginable, IMO, to
> rely on Unifont as the solution.
We may have no choice, at least in the short term.
Our mission -- replacing nonfree software with free software -- is hard
enough. I don't think it is wise to make it harder by demanding we
compete with nonfree software on esthetic points.
However, it would be good to show the community that we are looking for
people to design free repacements for those nonfree font extensions.
I will discuss the issue with someone that works on free fonts.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 00:56:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
We could hold a campaign to try to persuade Douros. It is outside the
topic here -- would anyone interested please email me?
> - New versions of Unicode have come and gone since then; they have
> introduced new blocks and new characters (cf. the initial bug report).
Would you like to tell me what scripts have been added since then?
And which characters?
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 08:37:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 41747 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> However, it would be good to show the community that we are looking for
> people to design free repacements for those nonfree font extensions.
> I will discuss the issue with someone that works on free fonts.
NB: as highlighted earlier in the thread[1], there already are some free
fonts covering the newer characters.
They are color fonts though, so I don't think it would make sense to use
them just for "Symbols and Pictographs Extended-A": I expect users would
find it jarring if Emacs displayed emoji from this specific block with a
color font, yet displayed all others with a "regular"[2] font.
IMO the best way forward would be to consult Unicode's emoji list[3],
and enrich setup-default-fontset by iterating over every range and
(set-fontset-font "fontset-default" range
'("Noto Color Emoji" . "iso10646-1") nil 'prepend)
The (somewhat) complicated part is listing all ranges; it's not clear to
me yet if we want to do this manually, at compile-time, or once per
Unicode release, using scripts under admin/.
[1] <871rmpclzf.fsf <at> gmail.com>
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41747#22
[2] Non-color? Black? Monochrome? 😕
[3] https://www.unicode.org/Public/UCD/latest/ucd/emoji/emoji-data.txt
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 08:51:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 41747 <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> > - New versions of Unicode have come and gone since then; they have
> > introduced new blocks and new characters (cf. the initial bug report).
>
> Would you like to tell me what scripts have been added since then?
> And which characters?
IIUC the last free version of Symbola covers everything in Unicode 10;
going through all Unicode changelogs since then[1] and checking which
new scripts and characters are covered by new versions of Symbola would
take a bit more time than I have on my hands right now. Sorry.
[1] https://www.unicode.org/charts/PDF/Unicode-11.0/
https://www.unicode.org/charts/PDF/Unicode-12.0/
https://www.unicode.org/charts/PDF/Unicode-12.1/
https://www.unicode.org/charts/PDF/Unicode-13.0/
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 14:39:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Richard Stallman <rms <at> gnu.org>
> Cc: 41747 <at> debbugs.gnu.org, kevin.legouguec <at> gmail.com
> Date: Tue, 09 Jun 2020 20:53:21 -0400
>
> > Specifically, for displaying emoji it would be unimaginable, IMO, to
> > rely on Unifont as the solution.
>
> We may have no choice, at least in the short term.
> Our mission -- replacing nonfree software with free software -- is hard
> enough. I don't think it is wise to make it harder by demanding we
> compete with nonfree software on esthetic points.
That may be true, but I wrote that to answer your question: why using
Unifont constitutes a failure.
> However, it would be good to show the community that we are looking for
> people to design free repacements for those nonfree font extensions.
> I will discuss the issue with someone that works on free fonts.
There are already free fonts that cover these new characters, we just
need to add their support to Emacs. There's a TODO item about
extending emoji support.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Wed, 10 Jun 2020 14:50:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 41747 <at> debbugs.gnu.org (full text, mbox):
> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 41747 <at> debbugs.gnu.org
> Date: Wed, 10 Jun 2020 10:36:44 +0200
>
> They are color fonts though, so I don't think it would make sense to use
> them just for "Symbols and Pictographs Extended-A": I expect users would
> find it jarring if Emacs displayed emoji from this specific block with a
> color font, yet displayed all others with a "regular"[2] font.
>
> IMO the best way forward would be to consult Unicode's emoji list[3],
> and enrich setup-default-fontset by iterating over every range and
>
> (set-fontset-font "fontset-default" range
> '("Noto Color Emoji" . "iso10646-1") nil 'prepend)
That's part of the TODO item for better emoji support in Emacs.
> The (somewhat) complicated part is listing all ranges; it's not clear to
> me yet if we want to do this manually, at compile-time, or once per
> Unicode release, using scripts under admin/.
The latter, of course. This is also in TODO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Thu, 11 Jun 2020 03:37:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
> IIUC the last free version of Symbola covers everything in Unicode 10;
Thanks. I think that is enough for me to understand what is missing.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Thu, 11 Jun 2020 03:41:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 41747 <at> debbugs.gnu.org (full text, mbox):
[[[ 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. ]]]
> There are already free fonts that cover these new characters, we just
> need to add their support to Emacs. There's a TODO item about
> extending emoji support.
I am surprised, but glad, that fixing this is so easy. The word
"SNAFU" seemed to imply that we had a difficult problem on our hands.
--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Thu, 11 Jun 2020 20:59:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 41747 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jun 10, 2020 at 10:36:44AM +0200, Kévin Le Gouguec wrote:
> NB: as highlighted earlier in the thread[1], there already are some free
> fonts covering the newer characters.
>
> They are color fonts though, so I don't think it would make sense to use
> them just for "Symbols and Pictographs Extended-A": I expect users would
> find it jarring if Emacs displayed emoji from this specific block with a
> color font, yet displayed all others with a "regular"[2] font.
There's a "Noto Emoji" font which, iirc, is simply a non-colour
version of Noto Color Emoji.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#41747
; Package
emacs
.
(Thu, 11 Jun 2020 21:04:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 41747 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jun 11, 2020 at 09:58:31PM +0100, Alan Third wrote:
> There's a "Noto Emoji" font which, iirc, is simply a non-colour
> version of Noto Color Emoji.
I just did what I should have done before sending this email and
checked the status of Noto Emoji. It's no longer supported and
therefore out of date. Sorry for the noise.
--
Alan Third
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 10 Jul 2020 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 32 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.