FS#76076 - [xterm] 373 [Orphan] ignores xft.dpi xresource
Attached to Project:
Arch Linux
Opened by Gabor Hauzer (cysp74) - Friday, 30 September 2022, 16:20 GMT
Last edited by Toolybird (Toolybird) - Saturday, 15 October 2022, 21:08 GMT
Opened by Gabor Hauzer (cysp74) - Friday, 30 September 2022, 16:20 GMT
Last edited by Toolybird (Toolybird) - Saturday, 15 October 2022, 21:08 GMT
|
Details
Description:
It's very likely an upstream bug, new xterm 373 doesn't respect xft.dpi, however it worked and used flawlessly in 372. Steps to reproduce: Set xft.dpi in xresources, xrdb -load <xresource>, launch xterm. nothing will happen. Checked under xorg. |
This task depends upon
Closed by Toolybird (Toolybird)
Saturday, 15 October 2022, 21:08 GMT
Reason for closing: Fixed
Additional comments about closing: xterm 374-1
Saturday, 15 October 2022, 21:08 GMT
Reason for closing: Fixed
Additional comments about closing: xterm 374-1
As per the Arch bug guidelines [1] you really must report this upstream.
[1] https://wiki.archlinux.org/title/Bug_reporting_guidelines#Upstream_or_Arch%3F
> As per the Arch bug guidelines [1] you really must report this upstream.
- Already happened before I opened this ticket.
- As I told it's very likely, but not sure, since the developer told last change shouldn't cause this kind of behavior.
Ty
Overriding the DPI via .config/fontconfig/fonts.conf was workaround for me (using debian unstable but that should not make a difference. This here was the only complaint about the broken DPI-calculation in 373 I could find).
In the meantime I was able to debug the origin of problem, and it's coming from a newly inserted code snippet of xterm (fontutils.c) and I'm in touch w/ developer. So, this issue intro'd by new package of 373 xterm comes from upstream.
Ty