GNU bug report logs - #73752
29.4; Ligatures are randomly rendered with extra spaces

Previous Next

Package: emacs;

Reported by: xuan <at> xlk.me

Date: Fri, 11 Oct 2024 21:40:02 UTC

Severity: normal

Merged with 54646

Found in versions 29.0.50, 29.4

Fixed in version 30.1

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Yixuan Chen <xuan <at> xlk.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 73752 <at> debbugs.gnu.org, visuweshm <at> gmail.com
Subject: bug#73752: 29.4; Ligatures are randomly rendered with extra spaces
Date: Mon, 28 Oct 2024 11:20:29 -0400
[Message part 1 (text/plain, inline)]
On 10/28/24 11:05, Eli Zaretskii wrote:
>> Date: Mon, 28 Oct 2024 10:44:23 -0400
>> Cc: visuweshm <at> gmail.com, luangruo <at> yahoo.com, 73752 <at> debbugs.gnu.org
>> From: Yixuan Chen <xuan <at> xlk.me>
>>
>>> Is
>>> that extra space a real SPC glyph or is it just that the ligature is
>>> considered "wider"?  What happens if you put the cursor on the ▷
>>> ligature in the "bad" display -- does the block cursor then take up
>>> all the space up to the next quote?
>>
>> It's not a real SPC glyph. It's a single character ▷ (or ligature/glyph
>> I should call it? the underlying text is "|||>"). I attached five
>> screenshots, where the block cursor is at ", |, |, |, >, " respectively.
>> Noticeably, the block cursor for the first | character (1_bar.png) is
>> extra wide, and the block cursors for the following characters looks
>> offset from where they are.
> 
> According to the screenshots, it actually looks like it's a real SPC
> glyph or something.  What does "C-u C-x =" show when the block cursor
> is shown as below?

It shows
>              position: 1277 of 3527 (36%), column: 34
>             character: > (displayed as >) (codepoint 62, #o76, #x3e)
>               charset: ascii (ASCII (ISO646 IRV))
> code point in charset: 0x3E
>                script: latin
>                syntax: _ 	which means: symbol
>              category: .:Base, a:ASCII, l:Latin, r:Roman
>              to input: type "C-x 8 RET 3e" or "C-x 8 RET GREATER-THAN SIGN"
>           buffer code: #x3E
>             file code: #x3E (encoded by coding system utf-8-unix)
>               display: by this font (glyph code):
>     ftcrhb:-SAJA-Cascadia Code-light-normal-normal-*-17-*-*-*-m-0-iso10646-1 (#x810)
> 
> Character code properties: customize what to show
>   name: GREATER-THAN SIGN
>   general-category: Sm (Symbol, Math)
>   decomposition: (62) ('>')
> 
> There are text properties here:
>   face                 (face12 font-lock-string-face)
>   fontified            t

> Actually, how about showing what "C-u C-x =" says in each of the 6
> positions you show?  And then show what "C-u C-x =" says in the same 6
> positions in the "good" display?

See "bad.txt" for the output of the bad emacs display, and "good.txt" 
for the output of good emacs display. I also attached the block cursor 
screenshots for good emacs display.
[good.txt (text/plain, attachment)]
[bad.txt (text/plain, attachment)]
[0.png (image/png, attachment)]
[1.png (image/png, attachment)]
[2.png (image/png, attachment)]
[3.png (image/png, attachment)]
[4.png (image/png, attachment)]
[5.png (image/png, attachment)]

This bug report was last modified 252 days ago.

Previous Next


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