GNU bug report logs -
#42366
UTF8 QR codes vs. emacs
Previous Next
Reported by: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Date: Wed, 15 Jul 2020 14:22:02 UTC
Severity: normal
Tags: notabug
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42366 in the body.
You can then email your comments to 42366 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#42366
; Package
emacs
.
(Wed, 15 Jul 2020 14:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 15 Jul 2020 14:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Compare how
$ qrencode -t UTF8 x
looks in
$ emacs -nw -f shell # vs.
$ emacs -f shell
As you can see in the latter it is quite mangled,
perhaps beyond machine recognition.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 16 Jul 2020 16:00:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 42366 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 15 Jul 2020 22:20:45 +0800, 積丹尼 Dan Jacobson <jidanni <at> jidanni.org> said:
積丹尼> Compare how
積丹尼> $ qrencode -t UTF8 x
積丹尼> looks in
積丹尼> $ emacs -nw -f shell # vs.
積丹尼> $ emacs -f shell
積丹尼> As you can see in the latter it is quite mangled,
積丹尼> perhaps beyond machine recognition.
Using which font on which platform?
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 16 Jul 2020 17:45:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 42366 <at> debbugs.gnu.org (full text, mbox):
>>>>> "RP" == Robert Pluim <rpluim <at> gmail.com> writes:
RP> Using which font on which platform?
Mmmm... the majority.
How about yours. Can you take a screenshot of it, scan it with e.g.,
zbarimg, and have it still be decoded successfully?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 10:28:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 42366 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
積丹尼 Dan Jacobson <jidanni <at> jidanni.org> writes:
> Compare how
> $ qrencode -t UTF8 x
> looks in
> $ emacs -nw -f shell # vs.
> $ emacs -f shell
>
> As you can see in the latter it is quite mangled,
> perhaps beyond machine recognition.
It's not good in any case, really. Here's the X version:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Note the horizontal lines -- it should be a solid white field.
And with -nw it's just a complete mess:
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
I guess... it's translating all the Unicode characters instead of just
letting the terminal render them? The terminal does have these
characters; when running the program directly in the shell everything
works fine.
Does anybody know how to make shell-mode (under -nw) just output the
characters?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 10:45:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 42366 <at> debbugs.gnu.org (full text, mbox):
On Aug 05 2020, Lars Ingebrigtsen wrote:
> Note the horizontal lines -- it should be a solid white field.
That's just a matter of using a proper font.
> Does anybody know how to make shell-mode (under -nw) just output the
> characters?
Worksforme. Try using a UTF-8 environment.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 10:54:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 42366 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> linux-m68k.org> writes:
> On Aug 05 2020, Lars Ingebrigtsen wrote:
>
>> Note the horizontal lines -- it should be a solid white field.
>
> That's just a matter of using a proper font.
Emacs doesn't select the proper font automatically here, which it should?
>> Does anybody know how to make shell-mode (under -nw) just output the
>> characters?
>
> Worksforme. Try using a UTF-8 environment.
Oh, yeah. With emacs -Q this works fine for me under Emacs -nw. So I
don't think there's any bugs here, and I'm closing this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Aug 2020 10:54:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
42366 <at> debbugs.gnu.org and 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 05 Aug 2020 10:54:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 14:21:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Wed, 05 Aug 2020 12:26:55 +0200
> Cc: 42366 <at> debbugs.gnu.org
>
> > Compare how
> > $ qrencode -t UTF8 x
> > looks in
> > $ emacs -nw -f shell # vs.
> > $ emacs -f shell
> >
> > As you can see in the latter it is quite mangled,
> > perhaps beyond machine recognition.
>
> It's not good in any case, really. Here's the X version:
Can you send the file itself?
> Note the horizontal lines -- it should be a solid white field.
How do you know that?
> And with -nw it's just a complete mess:
No, it isn't...
> I guess... it's translating all the Unicode characters instead of just
> letting the terminal render them? The terminal does have these
> characters; when running the program directly in the shell everything
> works fine.
That's what happens when Emacs thinks your terminal cannot display
these characters. What does 'terminal-coding-system' return on that
display?
> Does anybody know how to make shell-mode (under -nw) just output the
> characters?
Hmm... shell-mode? Now I'm beginning to think I don't really
understand what are the steps to reproduce the problem, and what is
their meaning (jidanni needs to learn how to report bugs clearly).
Would you please describe the steps, starting from "emacs -Q"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 14:23:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 42366 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Wed, 05 Aug 2020 12:26:55 +0200
>> Cc: 42366 <at> debbugs.gnu.org
>>
>> > Compare how
>> > $ qrencode -t UTF8 x
>> > looks in
>> > $ emacs -nw -f shell # vs.
>> > $ emacs -f shell
>> >
>> > As you can see in the latter it is quite mangled,
>> > perhaps beyond machine recognition.
>>
>> It's not good in any case, really. Here's the X version:
>
> Can you send the file itself?
There's no file -- it's just the output from the qrencode command.
>> Note the horizontal lines -- it should be a solid white field.
>
> How do you know that?
Because that's how it displays in the shell:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
And besides, a QR Code isn't supposed to have horizontal lines like
that.
> Hmm... shell-mode? Now I'm beginning to think I don't really
> understand what are the steps to reproduce the problem, and what is
> their meaning (jidanni needs to learn how to report bugs clearly).
> Would you please describe the steps, starting from "emacs -Q"?
There's not much to it: Run the qrencode program:
$ qrencode -t UTF8 x
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 14:49:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jidanni <at> jidanni.org, 42366 <at> debbugs.gnu.org
> Date: Wed, 05 Aug 2020 16:22:33 +0200
>
> > Can you send the file itself?
>
> There's no file -- it's just the output from the qrencode command.
Can you redirect the output to a file?
> And besides, a QR Code isn't supposed to have horizontal lines like
> that.
As Andreas says, this depends on the font. Some fonts leave a pixel
between this line and the next when they design these "characters".
> > Hmm... shell-mode? Now I'm beginning to think I don't really
> > understand what are the steps to reproduce the problem, and what is
> > their meaning (jidanni needs to learn how to report bugs clearly).
> > Would you please describe the steps, starting from "emacs -Q"?
>
> There's not much to it: Run the qrencode program:
>
> $ qrencode -t UTF8 x
So you are saying that your problem with \uNNNN was because you used
an incorrect locale? IOW, that there's no bug here at all?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 14:55:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 42366 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> There's no file -- it's just the output from the qrencode command.
>
> Can you redirect the output to a file?
Sure, it's just a bunch of UTF-8. I guess I could also just include the
data here:
█████████████████████████████
█████████████████████████████
████ ▄▄▄▄▄ █▀ █ ▄█ ▄▄▄▄▄ ████
████ █ █ █▄ █▀▄█ █ █ ████
████ █▄▄▄█ █ ██▀ █ █▄▄▄█ ████
████▄▄▄▄▄▄▄█ ▀ ▀ █▄▄▄▄▄▄▄████
████ ▀▄▀▀▄ █ ▄███ ▄▄█ █████
██████ ▄ ▄▄▀▄█▄▀▄▄███▀▀ ████
████▄▄▄▄▄▄▄█ ▀▀▄█▄▀ ▀▄▀▀████
████ ▄▄▄▄▄ █▄▄█▀▀ █ ▀▀▄▄█████
████ █ █ █▀▄▄ ██▄▄▄ ████
████ █▄▄▄█ █▀█ █▄▀▀█ █▀█▄████
████▄▄▄▄▄▄▄█▄█▄▄▄███▄▄▄▄█████
█████████████████████████████
█████████████████████████████
I've also included as an attachment, in case that doesn't work, for some
reason.
> So you are saying that your problem with \uNNNN was because you used
> an incorrect locale? IOW, that there's no bug here at all?
Yes. Except for the horizontal lines in the X version of Emacs.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[qr.bin (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 15:04:01 GMT)
Full text and
rfc822 format available.
Message #39 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: jidanni <at> jidanni.org, 42366 <at> debbugs.gnu.org
> Date: Wed, 05 Aug 2020 16:54:32 +0200
>
> > Can you redirect the output to a file?
>
> Sure, it's just a bunch of UTF-8. I guess I could also just include the
> data here:
Thanks. FWIW, with the default font my Emacs uses, I see no lines.
> > So you are saying that your problem with \uNNNN was because you used
> > an incorrect locale? IOW, that there's no bug here at all?
>
> Yes. Except for the horizontal lines in the X version of Emacs.
Can you try other fonts, and see if some of them eliminate the
problem? I think this is simply a matter of the shell window and the
terminal emulator using different fonts.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 15:34:03 GMT)
Full text and
rfc822 format available.
Message #42 received at 42366 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> On Wed, 05 Aug 2020 18:03:22 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> Yes. Except for the horizontal lines in the X version of Emacs.
Eli> Can you try other fonts, and see if some of them eliminate the
Eli> problem? I think this is simply a matter of the shell window and the
Eli> terminal emulator using different fonts.
Iʼm not sure about that. On macOS, this is
emacs -Q -font Consolas
[emacs-consolas.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
And this is the same build, but in a terminal window using Consolas
[emacs-nw-consolas.png (image/png, attachment)]
[Message part 5 (text/plain, inline)]
In the gui version, the cursor looks like it extends 1 pixel below
each component character, whilst in the '-nw' on the bottom of the
cursor lines up exactly.
If I use something else like Menlo, there are horizontal white lines,
but the cursor lines up with the bottom of the characters.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 15:39:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 42366 <at> debbugs.gnu.org,
> jidanni <at> jidanni.org
> Date: Wed, 05 Aug 2020 17:33:10 +0200
>
>
> [1:text/plain Hide]
>
> And this is the same build, but in a terminal window using Consolas
What exactly is surprising here? In a TTY frame, Emacs doesn't
control the layout: the terminal emulator does. Emacs just sends
codes to the terminal device, and that's it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 15:43:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 05 Aug 2020 18:38:38 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: larsi <at> gnus.org, 42366 <at> debbugs.gnu.org, jidanni <at> jidanni.org
>
> What exactly is surprising here? In a TTY frame, Emacs doesn't
> control the layout: the terminal emulator does. Emacs just sends
> codes to the terminal device, and that's it.
To clarify: the original complaint, AFAIU, was about the display in a
GUI frame, in which case the layout is entirely ours. You are now
saying that the problem is on TTY frames, but there we don't control
the layout at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 16:50:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 42366 <at> debbugs.gnu.org (full text, mbox):
On Aug 05 2020, Robert Pluim wrote:
> Iʼm not sure about that. On macOS, this is
>
> emacs -Q -font Consolas
>
>
>
>
> And this is the same build, but in a terminal window using Consolas
And as you can see, each program has its own warts.
FWIW, with Liberation Mono, I see perfect lineup.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Wed, 05 Aug 2020 17:48:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 42366 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> > So you are saying that your problem with \uNNNN was because you used
>> > an incorrect locale? IOW, that there's no bug here at all?
>>
>> Yes. Except for the horizontal lines in the X version of Emacs.
>
> Can you try other fonts, and see if some of them eliminate the
> problem? I think this is simply a matter of the shell window and the
> terminal emulator using different fonts.
Yeah, it's probably just a font issue, so I don't think it's worth
investigating any further. QR codes in Emacs is a rather obscure use
case. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 06 Aug 2020 07:58:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 42366 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Wed, 05 Aug 2020 18:42:11 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> Date: Wed, 05 Aug 2020 18:38:38 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: larsi <at> gnus.org, 42366 <at> debbugs.gnu.org, jidanni <at> jidanni.org
>>
>> What exactly is surprising here? In a TTY frame, Emacs doesn't
>> control the layout: the terminal emulator does. Emacs just sends
>> codes to the terminal device, and that's it.
Eli> To clarify: the original complaint, AFAIU, was about the display in a
Eli> GUI frame, in which case the layout is entirely ours. You are now
Eli> saying that the problem is on TTY frames, but there we don't control
Eli> the layout at all.
I donʼt think I said that. The TTY frame layout looks ok, the gui
frame one has what looks like extra pixels between the characters.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 06 Aug 2020 13:46:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: larsi <at> gnus.org, 42366 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> Date: Thu, 06 Aug 2020 09:57:04 +0200
>
> Eli> To clarify: the original complaint, AFAIU, was about the display in a
> Eli> GUI frame, in which case the layout is entirely ours. You are now
> Eli> saying that the problem is on TTY frames, but there we don't control
> Eli> the layout at all.
>
> I donʼt think I said that. The TTY frame layout looks ok, the gui
> frame one has what looks like extra pixels between the characters.
Then I don't think I understand what you are saying when I look at the
screenshots you posted. When you say "between the characters", do you
mean between two successive lines (i.e., vertically), or do you mean
between two adjacent characters on the same line?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 06 Aug 2020 14:37:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 42366 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 06 Aug 2020 16:44:59 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: larsi <at> gnus.org, 42366 <at> debbugs.gnu.org, jidanni <at> jidanni.org
>> Date: Thu, 06 Aug 2020 09:57:04 +0200
>>
Eli> To clarify: the original complaint, AFAIU, was about the display in a
Eli> GUI frame, in which case the layout is entirely ours. You are now
Eli> saying that the problem is on TTY frames, but there we don't control
Eli> the layout at all.
>>
>> I donʼt think I said that. The TTY frame layout looks ok, the gui
>> frame one has what looks like extra pixels between the characters.
Eli> Then I don't think I understand what you are saying when I look at the
Eli> screenshots you posted. When you say "between the characters", do you
Eli> mean between two successive lines (i.e., vertically), or do you mean
Eli> between two adjacent characters on the same line?
I meant between two adjacent characters (did I mix up the screenshots?
entirely possible).
With Liberation Mono, I see thin horizontal white lines (ie between
successive lines)
I guess we could put this all down to font differences.
Robert
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#42366
; Package
emacs
.
(Thu, 06 Aug 2020 14:42:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 42366 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: larsi <at> gnus.org, 42366 <at> debbugs.gnu.org, jidanni <at> jidanni.org
> Date: Thu, 06 Aug 2020 16:35:53 +0200
>
> I meant between two adjacent characters (did I mix up the screenshots?
> entirely possible).
>
> With Liberation Mono, I see thin horizontal white lines (ie between
> successive lines)
Ah, yes: I think you mixed up the images.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 04 Sep 2020 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.