GNU bug report logs - #77151
31.0.50; >>= is not rendered

Previous Next

To reply to this bug, email your comments to 77151 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; >>= is not rendered
Date: Fri, 21 Mar 2025 13:41:57 +0100

Hi,

From emacs -Q you can evaluate the following code:

(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
(package-initialize)

(set-face-font 'default "Fira Code")

(use-package ligature
:ensure t
:config
;; Enable the "www" ligature in every possible major mode
(ligature-set-ligatures 't '("www"))
;; Enable traditional ligature support in eww-mode, if the
;; `variable-pitch' face supports it
(ligature-set-ligatures 'eww-mode '("ff" "fi" "ffi"))
;; Enable all Fira Code ligatures in programming modes
(ligature-set-ligatures 'prog-mode '((">" (rx (+ (or ">" "<" "|" "/" ":" 
"=" "-"))))))
;; Enables ligature checks globally in all buffers. You can also do it
;; per mode with `ligature-mode'.
(global-ligature-mode t)
(message "`ligature' loaded"))

Now, if you open /tmp/test.el and write >>=, it won't be rendered, but
if you add any character (like = or :) it will.

I also tested it with emacs 30.1

Mattias

In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
3.24.43, cairo version 1.18.2) of 2025-03-17 built on mattias-pc
Repository revision: d708ebe401a2001e764821b7e43d9e9aaa23ea95
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12401006
System Description: Nobara Linux 41 (KDE Plasma)

Configured using:
'configure --with-native-compilation --with-native-image-api
--with-modules --with-harfbuzz --without-compress-install
--with-threads --with-included-regex --with-x-toolkit=gtk3 --with-zlib
--with-jpeg --with-png --with-imagemagick --with-tiff --with-xpm
--with-gnutls --with-xft --with-xml2 --with-mailutils
--with-tree-sitter 'CFLAGS=-march=native -mtune=native -O2 -g3''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM XRANDR GTK3 ZLIB

Important settings:
value of $LC_COLLATE: C
value of $LC_CTYPE: en_US.UTF-8
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_US.UTF-8
value of $LC_NUMERIC: en_US.UTF-8
value of $LC_TIME: en_US.UTF-8
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Elisp/d

Minor modes in effect:
global-ligature-mode: t
ligature-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
minibuffer-regexp-mode: 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:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils project ffap thingatpt compile
text-property-search comint ansi-osc ansi-color ring comp-run
comp-common rx ligature cl-extra help-mode use-package-ensure
use-package-core finder-inf ligature-autoloads package browse-url xdg
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 inotify dynamic-setting system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 358461 16820) (symbols 48 15746 0)
(strings 32 118471 3297) (string-bytes 1 2943828) (vectors 16 35327)
(vector-slots 8 378479 10339) (floats 8 59 1) (intervals 56 571 0)
(buffers 992 13))

Message #8 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Roux <mattias <at> kojin.tech>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Fri, 21 Mar 2025 15:31:25 +0200

> Date: Fri, 21 Mar 2025 13:41:57 +0100
> From: Mattias Roux <mattias <at> kojin.tech>
> 
> Hi,
> 
>  From emacs -Q you can evaluate the following code:
> 
> (require 'package)
> (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
> (package-initialize)
> 
> (set-face-font 'default "Fira Code")
> 
> (use-package ligature
> :ensure t
> :config
> ;; Enable the "www" ligature in every possible major mode
> (ligature-set-ligatures 't '("www"))
> ;; Enable traditional ligature support in eww-mode, if the
> ;; `variable-pitch' face supports it
> (ligature-set-ligatures 'eww-mode '("ff" "fi" "ffi"))
> ;; Enable all Fira Code ligatures in programming modes
> (ligature-set-ligatures 'prog-mode '((">" (rx (+ (or ">" "<" "|" "/" ":" 
> "=" "-"))))))
> ;; Enables ligature checks globally in all buffers. You can also do it
> ;; per mode with `ligature-mode'.
> (global-ligature-mode t)
> (message "`ligature' loaded"))
> 
> Now, if you open /tmp/test.el and write >>=, it won't be rendered, but
> if you add any character (like = or :) it will.
> 
> I also tested it with emacs 30.1

Thanks, but did you report this to the developers of the "ligature"
package first?  If so, what did they say to indicate that this problem
is in Emacs and not in the package?

If you haven't reported this to the package developers yet, please do,
since the package is not part of Emacs.

Message #11 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Fri, 21 Mar 2025 18:46:30 +0100

As Mickey says when creating an issue:

> If you're experiencing one of the following problems:
>
> - Emacs crashes when you use `ligature.el`;
> - Some ligations are visually garbled, cut off, or not rendering at all;
> - No ligations are showing at all;
> - Weird interactions with non-ligated characters around a ligated 
character;
>
> Then it's very likely the issue is with **Emacs core**, and not 
`ligature.el`. This package merely interacts
> with the Emacs text shaping engine to configure your ligature 
settings. It does not, on its own, do any sort
> of ligation.

That's why I created this bug report but since you asked I also created 
an issue on the ligature repo: 
https://github.com/mickeynp/ligature.el/issues/59

On 21/03/2025 2:31 PM, Eli Zaretskii wrote:
>> Date: Fri, 21 Mar 2025 13:41:57 +0100
>> From: Mattias Roux <mattias <at> kojin.tech>
>>
>> Hi,
>>
>>   From emacs -Q you can evaluate the following code:
>>
>> (require 'package)
>> (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))
>> (package-initialize)
>>
>> (set-face-font 'default "Fira Code")
>>
>> (use-package ligature
>> :ensure t
>> :config
>> ;; Enable the "www" ligature in every possible major mode
>> (ligature-set-ligatures 't '("www"))
>> ;; Enable traditional ligature support in eww-mode, if the
>> ;; `variable-pitch' face supports it
>> (ligature-set-ligatures 'eww-mode '("ff" "fi" "ffi"))
>> ;; Enable all Fira Code ligatures in programming modes
>> (ligature-set-ligatures 'prog-mode '((">" (rx (+ (or ">" "<" "|" "/" ":"
>> "=" "-"))))))
>> ;; Enables ligature checks globally in all buffers. You can also do it
>> ;; per mode with `ligature-mode'.
>> (global-ligature-mode t)
>> (message "`ligature' loaded"))
>>
>> Now, if you open /tmp/test.el and write >>=, it won't be rendered, but
>> if you add any character (like = or :) it will.
>>
>> I also tested it with emacs 30.1
> Thanks, but did you report this to the developers of the "ligature"
> package first?  If so, what did they say to indicate that this problem
> is in Emacs and not in the package?
>
> If you haven't reported this to the package developers yet, please do,
> since the package is not part of Emacs.

Message #14 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Roux <mattias <at> kojin.tech>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Sat, 22 Mar 2025 10:16:55 +0200

> Date: Fri, 21 Mar 2025 18:46:30 +0100
> Cc: 77151 <at> debbugs.gnu.org
> From: Mattias Roux <mattias <at> kojin.tech>
> 
> As Mickey says when creating an issue:
> 
>  > If you're experiencing one of the following problems:
>  >
>  > - Emacs crashes when you use `ligature.el`;
>  > - Some ligations are visually garbled, cut off, or not rendering at all;
>  > - No ligations are showing at all;
>  > - Weird interactions with non-ligated characters around a ligated 
> character;
>  >
>  > Then it's very likely the issue is with **Emacs core**, and not 
> `ligature.el`. This package merely interacts
>  > with the Emacs text shaping engine to configure your ligature 
> settings. It does not, on its own, do any sort
>  > of ligation.
> 
> That's why I created this bug report but since you asked I also created 
> an issue on the ligature repo: 
> https://github.com/mickeynp/ligature.el/issues/59

Thanks.

Looking at what happens, I'm not sure I see a bug in Emacs here.  For
the ">>=" case (where you see no ligation), find-composition produces
the following:

  (267 270 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61]
	    1
	    [0 0 62 1650 10 0 0 15 5 nil]
	    [1 1 62 1390 10 -8 8 15 5 nil]
	    [2 2 61 1578 10 2 8 15 5 nil]])

Whereas for the ">>==" case, where you see ligation, it produces the
following:

  (467 471 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61 61]
	    3
	    [0 0 62 1650 10 0 0 15 5 nil]
	    [1 1 62 1469 10 -7 10 15 5 nil]
	    [2 2 61 1456 10 0 10 15 5 nil]
	    [3 3 61 1455 10 0 8 15 5 nil]])

(If you want to understand what these values mean, see the doc string
of composition-get-gstring.)

My conclusions from this are:

  . Emacs does recognize both cases as composable sequences
  . Emacs passes both sequences of characters to the shaping engine
  . The differences on display are because the shaping engine returned
    different sequences of font glyphs (the 4th element of the glyph
    vector) in each case

So the reason for this is probably in the font itself?  Maybe this
should be taken up with the developers of the fonts?  I see a very
similar behavior with Cascadia Code, so maybe these fonts assume or
require something which the particular ligatures you used violate?

Message #19 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Mon, 24 Mar 2025 14:37:14 +0100

[Message part 1 (text/plain, inline)]

Hi Eli,

Thanks for the thorough report :-)

I raised the issue on the FiraCode repository and here's the answer 
<https://github.com/tonsky/FiraCode/issues/1644#issuecomment-2748156170>:

Considering that it works literally everywhere else, it probably has 
something to do with Emacs

https://fonts.google.com/specimen/Fira+Code?preview.text=%3E%3E%3D

Image 
<https://private-user-images.githubusercontent.com/285292/426100705-b69cfdd7-0895-42f1-be0e-f2b0f3a24c90.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDI4MjM2MTEsIm5iZiI6MTc0MjgyMzMxMSwicGF0aCI6Ii8yODUyOTIvNDI2MTAwNzA1LWI2OWNmZGQ3LTA4OTUtNDJmMS1iZTBlLWYyYjBmM2EyNGM5MC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMzI0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDMyNFQxMzM1MTFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kMmI4MTIyNDRkY2QzZjQ1YjBlYWNlMWQ4ZTJmNGM4YjRjYzhkYzVlOTNiNDljZTNmNTBiMzkxOTdmYzFmYTFmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.f9_1FVImsqgkjFECPBIlzVYTHGkNL1wZEJThbEHf89U>

On 22/03/2025 9:16 AM, Eli Zaretskii wrote:
>> Date: Fri, 21 Mar 2025 18:46:30 +0100
>> Cc:77151 <at> debbugs.gnu.org
>> From: Mattias Roux<mattias <at> kojin.tech>
>>
>> As Mickey says when creating an issue:
>>
>>   > If you're experiencing one of the following problems:
>>   >
>>   > - Emacs crashes when you use `ligature.el`;
>>   > - Some ligations are visually garbled, cut off, or not rendering at all;
>>   > - No ligations are showing at all;
>>   > - Weird interactions with non-ligated characters around a ligated
>> character;
>>   >
>>   > Then it's very likely the issue is with **Emacs core**, and not
>> `ligature.el`. This package merely interacts
>>   > with the Emacs text shaping engine to configure your ligature
>> settings. It does not, on its own, do any sort
>>   > of ligation.
>>
>> That's why I created this bug report but since you asked I also created
>> an issue on the ligature repo:
>> https://github.com/mickeynp/ligature.el/issues/59
> Thanks.
>
> Looking at what happens, I'm not sure I see a bug in Emacs here.  For
> the ">>=" case (where you see no ligation), find-composition produces
> the following:
>
>    (267 270 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61]
> 	    1
> 	    [0 0 62 1650 10 0 0 15 5 nil]
> 	    [1 1 62 1390 10 -8 8 15 5 nil]
> 	    [2 2 61 1578 10 2 8 15 5 nil]])
>
> Whereas for the ">>==" case, where you see ligation, it produces the
> following:
>
>    (467 471 [[#<font-object "-outline-Fira Code-regular-normal-normal-*-16-*-*-*-c-*-iso8859-1"> 62 62 61 61]
> 	    3
> 	    [0 0 62 1650 10 0 0 15 5 nil]
> 	    [1 1 62 1469 10 -7 10 15 5 nil]
> 	    [2 2 61 1456 10 0 10 15 5 nil]
> 	    [3 3 61 1455 10 0 8 15 5 nil]])
>
> (If you want to understand what these values mean, see the doc string
> of composition-get-gstring.)
>
> My conclusions from this are:
>
>    . Emacs does recognize both cases as composable sequences
>    . Emacs passes both sequences of characters to the shaping engine
>    . The differences on display are because the shaping engine returned
>      different sequences of font glyphs (the 4th element of the glyph
>      vector) in each case
>
> So the reason for this is probably in the font itself?  Maybe this
> should be taken up with the developers of the fonts?  I see a very
> similar behavior with Cascadia Code, so maybe these fonts assume or
> require something which the particular ligatures you used violate?

[Message part 2 (text/html, inline)]

Message #22 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Roux <mattias <at> kojin.tech>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Tue, 25 Mar 2025 17:08:19 +0200

[Message part 1 (text/plain, inline)]

> Date: Mon, 24 Mar 2025 14:37:14 +0100
> Cc: 77151 <at> debbugs.gnu.org
> From: Mattias Roux <mattias <at> kojin.tech>
> 
> Thanks for the thorough report :-)
> 
> I raised the issue on the FiraCode repository and here's the answer:
> 
> Considering that it works literally everywhere else, it probably has something to do with Emacs
> 
> https://fonts.google.com/specimen/Fira+Code?preview.text=%3E%3E%3D

So I wanted to see if this is an Emacs problem or not.  I did two
things:

 . Tried the same in the Command Prompt of Windows 11, which on my
   system uses Cascadia Code font, which also supports these
   ligatures.  Lo and behold, it behaves the same: ">>=" produces
   something that doesn't look like a ligature (but if I watch
   carefully, I do see that when I type the second ">", the two ">>"
   together look differently than a single ">", so it's a different
   font glyph -- exactly like I saw in the output of
   find-composition).  And if I type ">>==", I get the ligature,
   exactly like in Emacs.

 . Invoked hb-view, the standalone shaping program that is part of
   HarfBuzz.  I invoked it like this:

     hb-view FiraCode-Regular.ttf --text=">>=" -o lig3.png -O png

   The resulting file lg3.png is attached.  You will see that it looks
   exactly like the "no-ligature" result in Emacs.  Then I tried the
   same with the 4-character sequence:

     hb-view FiraCode-Regular.ttf --text=">>==" -o lig4.png -O png

   The file lig4.png is also attached.  You will see that it shows the
   ligature, identical to what Emacs produces with these 4 characters.

So at this point I see no evidence that Emacs does anything wrong,
since the standalone HarfBuzz shaping program produces the same output
as what Emacs shows.  I wonder what am I missing, if indeed "every
other program does show the ligature" in the ">>=" case with the same
fonts.  Maybe the font developers could tell more about what other
applications do, since AFAIK they all use HarfBuzz.  Maybe they use
some optional features of the shaping?  (I tried to turn on kerning,
it didn't help.)

[lig3.png (image/png, attachment)]

[lig4.png (image/png, attachment)]

Message #25 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Tue, 25 Mar 2025 21:46:34 +0100

Hi Eli, thanks for the report :-)

I forwarded it to the FiraCode issue I opened

Message #28 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Roux <mattias <at> kojin.tech>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Wed, 26 Mar 2025 13:57:37 +0200

> Date: Tue, 25 Mar 2025 21:46:34 +0100
> Cc: 77151 <at> debbugs.gnu.org
> From: Mattias Roux <mattias <at> kojin.tech>
> 
> Hi Eli, thanks for the report :-)
> 
> I forwarded it to the FiraCode issue I opened

Thanks.  For posterity, the issue is here:

  https://github.com/tonsky/FiraCode/issues/1644

Message #31 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Roux <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Sun, 30 Mar 2025 23:54:35 +0200

[Message part 1 (text/plain, inline)]

Le 26/03/2025 à 12:57, Eli Zaretskii a écrit :
> Thanks.  For posterity, the issue is here:
>
>    https://github.com/tonsky/FiraCode/issues/1644

And for even more posterity, the bug comes from the font (and should be 
fixed in the next release): 
https://github.com/tonsky/FiraCode/issues/1644#issuecomment-2764733880

Thanks again for answering and investigating :-)

[Message part 2 (text/html, inline)]

Message #34 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Roux <mattias <at> kojin.tech>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Mon, 31 Mar 2025 15:51:02 +0300

> Date: Sun, 30 Mar 2025 23:54:35 +0200
> Cc: 77151 <at> debbugs.gnu.org
> From: Mattias Roux <mattias <at> kojin.tech>
> 
> Le 26/03/2025 à 12:57, Eli Zaretskii a écrit :
> 
>  Thanks.  For posterity, the issue is here:
> 
>   https://github.com/tonsky/FiraCode/issues/1644
> 
> And for even more posterity, the bug comes from the font (and should be fixed in the next release):
> https://github.com/tonsky/FiraCode/issues/1644#issuecomment-2764733880
> 
> Thanks again for answering and investigating :-) 

Thanks.  Would you please tell here when the next release of the font
is available?

Message #37 received at 77151 <at> debbugs.gnu.org (full text, mbox):

From: Mattias <mattias <at> kojin.tech>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77151 <at> debbugs.gnu.org
Subject: Re: bug#77151: 31.0.50; >>= is not rendered
Date: Mon, 31 Mar 2025 15:17:20 +0200

[Message part 1 (text/plain, inline)]

Le 31/03/2025 à 14:51, Eli Zaretskii a écrit :
> Thanks.  Would you please tell here when the next release of the font
> is available?

Of course!

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.