Bug#960164: xterm: forceBoxChars mode + cjkWidth mode renders oddly
Package: xterm
Version: 356-1
Severity: minor
Steps to reproduce:
- Launch xterm in "CJK width" mode, forcing xterm to render
box-drawing characters itself:
xterm -cjk_width +fbx
- Run the following command to print some box-drawing characters:
python3 -c 'print("a\u2500\u2500\u2500b\na\u2550\u2550\u2550b\n")'
Expected results:
In non-CJK-width mode, all the printed characters are one character-cell
wide, so the output looks like this (assuming the browser/email client
you're using also uses non-CJK-width mode):
a───b
a═══b
However, the box-drawing characters are "East-Asian Width: Ambiguous"
in Unicode, so in CJK-width mode they should occupy 2 character cells,
looking something like this:
a──b
a══b
Actual results:
a─── b
a═ ═ ═ b
For the second line, I guess xterm doesn't actually treat those box-drawing
characters specially, so it just pads them out, which is fair enough.
For the first line, though, xterm understands the box-drawing characters
should be wide, and it leaves room for them to be wide, but it draws them
narrow. At the very least, if it's going to draw them narrow it should pad
them out like the second line, but if it's going to draw them it might as
well draw them the correct width to begin with.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages xterm depends on:
ii libc6 2.30-4
ii libfontconfig1 2.13.1-4
ii libfreetype62.10.1-2
ii libice6 2:1.0.9-2
ii libtinfo6 6.2-1
ii libutempter01.1.6-6
ii libx11-62:1.6.9-2+b1
ii libxaw7 2:1.0.13-1+b2
ii libxext62:1.3.3-1+b2
ii libxft2 2.3.2-2
ii libxinerama12:1.1.4-2
ii libxmu6 2:1.1.2-2+b3
ii libxpm4 1:3.5.12-1
ii libxt6 1:1.1.5-1+b3
ii xbitmaps1.1.1-2
Versions of packages xterm recommends:
ii x11-utils 7.7+5
Versions of packages xterm suggests:
pn xfonts-cyrillic
-- no debconf information
Processed: reassign 960101 to src:node-jsonld, fixed 960101 in 1.6.2-5, reassign 959390 to src:gtk+3.0 ...
Processing commands for cont...@bugs.debian.org:
> reassign 960101 src:node-jsonld 1.6.2-3
Bug #960101 {Done: Jonas Smedegaard }
[node-jsonld,node-rdf-canonize] node-jsonld: Build with babel version 7
Bug reassigned from package 'node-jsonld,node-rdf-canonize' to
'src:node-jsonld'.
Ignoring request to alter found versions of bug #960101 to the same values
previously set
No longer marked as fixed in versions node-jsonld/1.6.2-5.
Bug #960101 {Done: Jonas Smedegaard } [src:node-jsonld]
node-jsonld: Build with babel version 7
Marked as found in versions node-jsonld/1.6.2-3.
> fixed 960101 1.6.2-5
Bug #960101 {Done: Jonas Smedegaard } [src:node-jsonld]
node-jsonld: Build with babel version 7
The source 'node-jsonld' and version '1.6.2-5' do not appear to match any
binary packages
Marked as fixed in versions node-jsonld/1.6.2-5.
> reassign 959390 src:gtk+3.0 3.24.18-1
Bug #959390 {Done: Sebastien Bacher }
[src:adwaita-icon-theme, src:gtk+3.0] adwaita-icon-theme breaks gtk+3.0
autopkgtest: gtk+/icontheme.test (Child process killed by signal 5)
Bug reassigned from package 'src:adwaita-icon-theme, src:gtk+3.0' to
'src:gtk+3.0'.
No longer marked as found in versions adwaita-icon-theme/3.36.1-1 and
gtk+3.0/3.24.18-1.
No longer marked as fixed in versions gtk+3.0/3.24.20-1.
Bug #959390 {Done: Sebastien Bacher } [src:gtk+3.0]
adwaita-icon-theme breaks gtk+3.0 autopkgtest: gtk+/icontheme.test (Child
process killed by signal 5)
Marked as found in versions gtk+3.0/3.24.18-1.
> fixed 959390 3.24.20-1
Bug #959390 {Done: Sebastien Bacher } [src:gtk+3.0]
adwaita-icon-theme breaks gtk+3.0 autopkgtest: gtk+/icontheme.test (Child
process killed by signal 5)
Marked as fixed in versions gtk+3.0/3.24.20-1.
> reassign 958837 src:openxr-sdk-source 1.0.8~dfsg1-2
Bug #958837 {Done: Ryan Pavlik } [src:vulkan-loader,
src:openxr-sdk-source] vulkan-loader breaks openxr-sdk-source autopkgtest:
VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not declared
Bug reassigned from package 'src:vulkan-loader, src:openxr-sdk-source' to
'src:openxr-sdk-source'.
No longer marked as found in versions openxr-sdk-source/1.0.8~dfsg1-2 and
vulkan-loader/1.2.135.0-2.
No longer marked as fixed in versions openxr-sdk-source/1.0.8~dfsg1-3.
Bug #958837 {Done: Ryan Pavlik } [src:openxr-sdk-source]
vulkan-loader breaks openxr-sdk-source autopkgtest:
VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not declared
Marked as found in versions openxr-sdk-source/1.0.8~dfsg1-2.
> fixed 958837 1.0.8~dfsg1-3
Bug #958837 {Done: Ryan Pavlik } [src:openxr-sdk-source]
vulkan-loader breaks openxr-sdk-source autopkgtest:
VK_DEBUG_REPORT_OBJECT_TYPE_OBJECT_TABLE_NVX_EXT’ was not declared
Marked as fixed in versions openxr-sdk-source/1.0.8~dfsg1-3.
> reassign 949723 python-jsonschema
Bug #949723 {Done: Michal Arbet }
[python-jsonschema,python-json-pointer] python-jsonschema's autopkg tests fail,
when python3-json-pointer is installed
Bug reassigned from package 'python-jsonschema,python-json-pointer' to
'python-jsonschema'.
Ignoring request to alter found versions of bug #949723 to the same values
previously set
No longer marked as fixed in versions python-jsonschema/3.2.0-1.
> fixed 949723 3.2.0-1
Bug #949723 {Done: Michal Arbet } [python-jsonschema]
python-jsonschema's autopkg tests fail, when python3-json-pointer is installed
There is no source info for the package 'python-jsonschema' at version
'3.2.0-1' with architecture ''
Unable to make a source version for version '3.2.0-1'
Marked as fixed in versions 3.2.0-1.
> found 960041 4.5.3-3
Bug #960041 [src:python-tornado4] python-tornado4: Pending removal
Marked as found in versions python-tornado4/4.5.3-3.
> tags 960041 + sid bullseye
Bug #960041 [src:python-tornado4] python-tornado4: Pending removal
Added tag(s) bullseye and sid.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
949723: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949723
958837: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958837
959390: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959390
960041: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960041
960101: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960101
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Processed: downgrade dependencies on libgl1-mesa-dri to Recommends:
Processing control commands: > found -1 19.3.3-1 Bug #960133 [libglx-mesa0] downgrade dependencies on libgl1-mesa-dri to Recommends: Marked as found in versions mesa/19.3.3-1. -- 960133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960133 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#960133: downgrade dependencies on libgl1-mesa-dri to Recommends:
Package: libglx-mesa0 Version: 18.3.6-2+deb10u1 Control: found -1 19.3.3-1 Severity: wishlist So far as I can tell, the usage of the DRI modules provided by libgl1-mesa-dri by libglx-mesa0 is either optional or dependent on the context. At the very least, circumventing these dependencies produces no apparent ill effects with the packages transitionally dependent on libglx-mesa0, such as x11-utils, xvfb (via libgl1), and so on. Given that the libgl1-mesa-dri package brings in some 60‒70 MB of Installed-Size: due to libllvm alone – and also on headless systems which cannot possibly benefit from having DRI modules available – could the dependency on libgl1-mesa-dri please be downgraded to Recommends:? Background I’m concerned with, specifically, the amount of runnable code in the (base) system – and its implications on security. I assume that /not/ having some package installed is ought to be the ultimate guarantee that no security flaw in said package is going to affect a given system. Hence is my interest in minimalistic Debian installs. As a workaround, I’ve installed an otherwise empty Provides: libgl1-mesa-dri package [1], produced with nope.sh [2], like: $ fakeroot -- nope libgl1-mesa-dri [1] http://am-1.org/~ivan/dist/no-libgl1-mesa-dri_0.1_all.deb [2] http://am-1.org/~ivan/src/nope.sh -- FSF associate member #7257 http://am-1.org/~ivan/
