Package: toilet
Version: 0.1-1
Severity: normal
Hi,
when I use a color filter, instead of the normal Unicode characters, I
get "invalid character" squares, so it seems that the filters somehow
break the output. A quick (< 1 minute) look at a hexdump didn't reveal
what exactly is wrong; I might follow up the bug report after
investigating a bit.
Simon
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages toilet depends on:
ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries
ii libcucul0 0.99.beta11.debian-2 low-level Unicode character drawin
ii toilet-fonts 0.1-1 collection of TOIlet fonts
ii zlib1g 1:1.2.3-13 compression library - runtime
toilet recommends no packages.
-- no debconf information
Subject: Re: Bug#408666: color filters break Unicode characters
Date: Sun, 28 Jan 2007 00:41:04 +0100
On Sat, Jan 27, 2007, Simon Richter wrote:
> when I use a color filter, instead of the normal Unicode characters, I
> get "invalid character" squares, so it seems that the filters somehow
> break the output. A quick (< 1 minute) look at a hexdump didn't reveal
> what exactly is wrong; I might follow up the bug report after
> investigating a bit.
I am unable to reproduce. Can you please send me the output of toilet
as well as the commandline you're using? Also, can you try different
terminal emulators?
Regards,
--
Sam.
On Sun, 28 Jan 2007 00:41:04 +0100 Sam Hocevar wrote:
> On Sat, Jan 27, 2007, Simon Richter wrote:
>
> > when I use a color filter, instead of the normal Unicode characters, I
> > get "invalid character" squares, so it seems that the filters somehow
> > break the output. A quick (< 1 minute) look at a hexdump didn't reveal
> > what exactly is wrong; I might follow up the bug report after
> > investigating a bit.
>
> I am unable to reproduce. Can you please send me the output of toilet
> as well as the commandline you're using? Also, can you try different
> terminal emulators?
I think I am able to reproduce the bug reported by Simon Richter.
The attached image is a shot of what I obtained on a uxterm (which
works fine with Unicode, as demonstrated in the image itself).
Simon, can you confirm that this is similar to what you saw when you
reported the bug?
Sam, can you help me understand what's wrong?
Is it a uxterm misconfiguration issue or indeed a toilet bug?
--
http://frx.netsons.org/doc/index.html#nanodocs
The nano-document series is here!
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Acknowledgement sent
to Sam Hocevar <[email protected]>:
Extra info received and forwarded to list. Copy sent to Sam Hocevar (Debian packages) <[email protected]>.
(Tue, 14 Jul 2009 10:57:07 GMT) (full text, mbox, link).
Subject: Re: Bug#408666: color filters break Unicode characters
Date: Tue, 14 Jul 2009 12:35:38 +0200
reassign 408666 xterm
retitle 408666 uxterm: bold attribute causes some glyphs to fail rendering
thanks
On Thu, Sep 18, 2008, Francesco Poli wrote:
> I think I am able to reproduce the bug reported by Simon Richter.
> The attached image is a shot of what I obtained on a uxterm (which
> works fine with Unicode, as demonstrated in the image itself).
I can confirm the problem. It seems to be due to uxterm failing
to render bold glyphs, as the following example shows:
echo ▜; tput bold; echo ▜
The second “▜” is rendered using the replacement character. Copy-
pasting that character yields the original “▜” glyph.
Regards,
--
Sam.
Changed Bug title to `uxterm: bold attribute causes some glyphs to fail rendering' from `color filters break Unicode characters'.
Request was from Sam Hocevar <[email protected]>
to [email protected].
(Tue, 14 Jul 2009 10:57:12 GMT) (full text, mbox, link).
Acknowledgement sent
to Francesco Poli <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Tue, 14 Jul 2009 17:03:03 GMT) (full text, mbox, link).
found 408666 243-1
thanks
On Tue, 14 Jul 2009 12:35:38 +0200 Sam Hocevar wrote:
> reassign 408666 xterm
> retitle 408666 uxterm: bold attribute causes some glyphs to fail rendering
> thanks
>
> On Thu, Sep 18, 2008, Francesco Poli wrote:
>
> > I think I am able to reproduce the bug reported by Simon Richter.
> > The attached image is a shot of what I obtained on a uxterm (which
> > works fine with Unicode, as demonstrated in the image itself).
>
> I can confirm the problem. It seems to be due to uxterm failing
> to render bold glyphs, as the following example shows:
>
> echo ▜; tput bold; echo ▜
>
> The second “▜” is rendered using the replacement character. Copy-
> pasting that character yields the original “▜” glyph.
Yes, I can reproduce the issue this way too.
I am using xterm/243-1: the above command should feed the BTS version
tracking accordingly...
--
New location for my website! Update your bookmarks!
http://www.inventati.org/frx
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Acknowledgement sent
to Ivan Shmakov <[email protected]>:
Extra info received and forwarded to list. Copy sent to Debian X Strike Force <[email protected]>.
(Sun, 19 Aug 2012 17:36:03 GMT) (full text, mbox, link).
Subject: Re: Bug#408666: bold attribute causes some glyphs to fail rendering
Date: Mon, 20 Aug 2012 00:14:42 +0700
>>>>> Francesco Poli <[email protected]> writes:
>>>>> On Tue, 14 Jul 2009 12:35:38 +0200 Sam Hocevar wrote:
[…]
>> I can confirm the problem. It seems to be due to uxterm failing to
>> render bold glyphs, as the following example shows:
>> echo ▜; tput bold; echo ▜
>> The second “▜” is rendered using the replacement character.
>> Copy-pasting that character yields the original “▜” glyph.
> Yes, I can reproduce the issue this way too. I am using xterm/243-1:
> the above command should feed the BTS version tracking accordingly...
While this bug is caused by the very same lack of glyphs in the
fonts XTerm is configured to use (and its inability to use,
roughly, more than one at a time), I believe it's an issue
sufficiently distinct from #449480 and #469943 (which were
merged in some three years ago), as it arises in the case of
discrepancies in the coverage between the -medium- and -bold-
variants of the same font.
It seems to me that this issue is somewhat deeper, as (according
to xterm(1)) it's possible to configure XTerm to ignore the bold
variant altogether and to rely on “overstruck” shapes instead:
--cut: xterm(1) --
alwaysBoldMode (class AlwaysBoldMode)
Specifies whether xterm should check if the normal and bold fonts
are distinct before deciding whether to use overstriking to
simulate bold fonts. If this resource is true, xterm does not
make the check for distinct fonts when deciding how to handle the
boldMode resource. The default is "false."
boldMode alwaysBoldMode Comparison Action
────────────────────────────────────────────────────
false false ignored use font
false true ignored use font
true false same overstrike
true false different use font
true true ignored overstrike
--cut: xterm(1) --
However, using $ xterm -xrm '*alwaysBoldMode: true' still
doesn't prevent XTerm from using the -bold- variant (as noticed
by missing glyphs.) The resource itself is not overridden, as
per editres(1).
OTOH, if (assuming default fonts) we're to switch to the “Huge”
font via the Ctrl+Button3 “Unicode Fonts” menu, the overstruck
shapes are used, as the font selected has no -bold- variant at
all.
(The code below was used to generate the test set of
characters.)
$ (s=$(perl -we 'use strict; binmode (STDOUT, ":utf8");
foreach my $i (64 .. 95, 0x2580 .. 0x259f) {
printf ("U+%04x : ", $i) if ($i % 16 == 0);
printf ("%s%s", chr ($i), ($i % 16 == 15 ? "\n" : ""));
}') ; \
tput bold ; printf %s\\n "$s" ; \
tput sgr0 ; printf %s\\n "$s")
--
FSF associate member #7257 http://sf-day.org/
Source: xterm
Source-Version: 287-1
We believe that the bug you reported is fixed in the latest version of
xterm, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Julien Cristau <[email protected]> (supplier of updated xterm package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Tue, 27 Nov 2012 22:27:28 +0100
Source: xterm
Binary: xterm
Architecture: source amd64
Version: 287-1
Distribution: experimental
Urgency: low
Maintainer: Debian X Strike Force <[email protected]>
Changed-By: Julien Cristau <[email protected]>
Description:
xterm - X terminal emulator
Closes: 359006408666683942691642694375
Changes:
xterm (287-1) experimental; urgency=low
.
* New upstream release (closes: #694375)
- add alternateScroll resource and corresponding control sequences which
modify the scroll-forw and scroll-back actions: when the alternate
screen is displayed, wheel mouse up/down will send cursor keys (closes:
#683942)
- improve rendering for the case when a Unicode character is absent in the
bold font but present in the normal font by temporarily falling back to
the normal font (closes: #359006, #408666)
- check for misconfigured printerCommand resource on the first use, warn
and disable it if it does not specify an executable command (closes:
#691642)
* Drop upstream patches.
* Refresh remaining patches.
* Explicitly set --with-desktop-category to avoid desktop-file-install
failure.
* Enable backarrowKeyIsErase in configure instead of 900_debian_xterm.diff.
* Install png/svg icons.
* Change xterm.man's NAME section to keep whatis(1) happy.
Checksums-Sha1:
2e3a950920d5a74b6aaec447454ead50ccda3998 2019 xterm_287-1.dsc
f1c4bfd11394eaa8158559cea63180fe7cc8d3ed 1103402 xterm_287.orig.tar.gz
465d898bac50303b06c68dcc9a7453ee74acc9b6 98825 xterm_287-1.diff.gz
e888c0d5ad201fc4037478fafe07161745c5c560 661918 xterm_287-1_amd64.deb
Checksums-Sha256:
f3eb17fceb50a7acb977c36c789812f39319c71b30aa97e7aaf6614cc6cd7d9a 2019 xterm_287-1.dsc
b5645b5963d01d15f62fb9071f743b58e4d158581f19f411bf14422519363956 1103402 xterm_287.orig.tar.gz
125172942397e818d450c52f5282777cb6c5d8e47b2dcbdd964991001ff2507e 98825 xterm_287-1.diff.gz
ce39c08b42cd7b9b61e4ba2037e26fdad8f28039e19ec931f3ed4f03d50070c7 661918 xterm_287-1_amd64.deb
Files:
b341950dad30c453b6c12fc968352c7b 2019 x11 optional xterm_287-1.dsc
0e4385e66d40b5dd6017d02c3db2a4af 1103402 x11 optional xterm_287.orig.tar.gz
721f7450a36270648a3bd77f1fce6690 98825 x11 optional xterm_287-1.diff.gz
0515e28e499ccb1f08d6c928cf32c5f9 661918 x11 optional xterm_287-1_amd64.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJQtTDSAAoJEDEBgAUJBeQMxtsP/0DCbmOhFELva5OpFJdwQWfW
mqJPHYS83JNNMQXwYS8IPNBcdpWfWGAT6YLdqgWqBcwUNkMx812nOvn/EDJtr6pG
DrsQim0Ysz/9NGSiKGqckuFcmySmOhCuhRjHmg48wk3ER/hTJWijyxUWsaqhsKqQ
lyeUW9Jw+nKpgqtpkGA85WGoPiDZh4O+sPwC1lNmlDiyw4nWAo2LJgmVJb1JugKH
+o/eEYdZinQBc0UiKnyYQmKUlmoJ+C7W+594/GEOVaeQTyAxNhMjmHqBWO1HglDw
WjBtRZk735LLXMFT9LWMXBbvydcnXUGKE9qSEZVWHDbIqBdJNh6lBm6nMJIMLp7S
/P7WheREZlwDqEOCYdkB/6M0FkSPCYZW5GI7/Lu6Gtm3FjMWIbcaOW8nEdBtiZJm
sDzwjzatxSUtL0iaVRPM+trCy4ynFU74nMCQ6XAFWaekY2g1oUaGAVXtofR2I/oi
3IYXpLXl/DmO4zwq+aMCgYzhvHoC2JzZnvrSt+5RYEsGhXEhakbiwI4G4YcRLbXc
YeYWAs07QKj4+IZ3nvIq5YgVqCUAZjpVlBYlkLFd7KsfTpAPi71NS/jB4L6Z7Foj
9jpqs8jtNjM+B7Rvt7ZF6GCP/f1XlFZRpzm1roL0YIdOvx66BVMOCfk1SSyzqsFX
fpj6xMPGzcI/tFfyFHC9
=E32r
-----END PGP SIGNATURE-----
Reply sent
to Julien Cristau <[email protected]>:
You have taken responsibility.
(Tue, 27 Nov 2012 21:51:15 GMT) (full text, mbox, link).