我有两个不同的桌面主机通过它们的 DisplayPort 输出连接到同一 4K 显示器上的两个 DisplayPort 输入：
- idyllic是一款使用 Celeron N3350 处理器的板载 Intel HD Graphics 500 的小型 PC。（据我所知，我在另一个地方也有一个类似的系统，它配备 Pentium N4200 处理器和 Intel 505 显卡，在 4K 下的功能相同。）
- logarithmic，一个相当通用的旧 ATX 系统，带有 Intel i5-3450 CPU 和 ATI Radeon 7870 显卡
两个系统都运行完全最新的 Debian 9，并且配置与我所能管理的一样。尤其是：
- 两个系统上的 X 服务器 DPI 都是 96，使用
grep DPI /var/log/Xorg.0.log和检查xdpyinfo | grep dots - 两个系统上的 Xft DPI 均为 120，使用
xrdb -query | grep dpi. - 两者都是
xrdb -cpp cpp -merge $HOME/.Xresources从一个相同的文件配置的，我已经确认xrdb -query在两者上产生相同的输出。~/.fonts我还在两个系统上加载了完全相同的一组 Source Code Pro 字体。
在它们中的任何一个上，我都可以启动一个 80 列的 xterm，配置为XTerm*VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1，它们看起来相同，宽度为 484 像素。如果我在显示在本地 X 服务器上的另一台机器上使用ssh -X.
但是，urxvt根据我使用的 X 服务器而有所不同。我已将字体 X 资源配置为：
Rxvt.font: xft:Source Code Pro:size=9,xft:Source Han Sans,xft:DejaVu Serif:size=8,xft:DejaVu Sans Mono:size=8
当我开始urxvt在idyllic的 X 服务器上显示时，无论是在本地还是在另一个主机上启动ssh -X时，垂直最大化时，一个 80 列的终端是 644 像素宽和 106 列高。但是，当我启动它以在logarithmic的 X 服务器上显示（再次在本地或使用远程客户端ssh -X）时，80 列urxvt是 726 像素宽，但在垂直最大化时仍然是 106 列高。
所以，问题：
是什么导致urxvt对数变宽，我如何使它与田园诗般的窄尺寸相同？即使您不知道，调试提示也将不胜感激。我很高兴编写与 X11 服务器对话的程序（更喜欢 Python 或类似的程序而不是 C 或类似的程序），并让我使用与urxvt正在做的类似的渲染来查看问题是否可以通过这种方式找到，如果你有具体的关于我应该调用哪些 API 以及我应该寻找什么样的结果的建议。
一个附带的问题：xft:字体是由 X 客户端呈现的，对吗？如果这是正确的，这似乎是一个很大的暗示，即 X11 服务器中的某些设置正在改变同一主机上的同一客户端渲染字体的方式，具体取决于它正在与之交谈的 X11 服务器。
编辑：xfce4-terminal信息
我尝试启动xfce4-terminal并将字体设置为 9 点 Source Code Pro 中等；它在两台 X11 服务器上的结果都是一样的，总是urxvt采用在logarithmic上使用的更广泛的格式。这似乎表明它与urxvt它本身或Xft库有关（如果xfce4-terminal不使用它；我很确定它会这样做urxvt），而不是 FreeType？
编辑：xtrace信息
我从xtrace（感谢@Uli Schlachter的想法！）那里获得了更多信息，这至少让我更详细地看到了问题所在。运行甚至只会xtrace urxvt -e true产生几百 KB 的输出，所以显然我不会在这里包含所有内容，但这里有一些关键位。下面的差异是会话idyllic →<em>idyllic 和idyllic →<em>logarithmic，即idyllic在两种情况下都运行，urxvt但首先显示在自身上，然后远程显示在logarithmic上。
在每个CreateWindow调用的第 156 行，确认创建的窗口具有相同的高度但不同的宽度，正如我上面提到的（我测量了一个窗口宽度死了，但其他两个像素没有）：
-000:<:005e: 48: Request(1): CreateWindow depth=0x18 window=0x03200009 parent=0x000000e7 x=0 y=0 width=644 height=904 border-width=0 class=InputOutput(0x0001) visual=0x00000021 value-list={background-pixel=0x00ffffe0 border-pixel=0x00ffffe0 override-redirect=false(0x00) colormap=0x00000020}
+000:<:005e: 48: Request(1): CreateWindow depth=0x18 window=0x05400009 parent=0x000004bb x=0 y=0 width=724 height=904 border-width=0 class=InputOutput(0x0001) visual=0x00000021 value-list={background-pixel=0x00ffffe0 border-pixel=0x00ffffe0 override-redirect=false(0x00) colormap=0x00000020}
从每行的第 138 行开始，我看到了这个差异（第二行为了理智而被截断），这似乎证实了width=7与width=9正在创建的字形相比，这是一个字符宽度问题。
-000:<:004c: 12: RENDER-Request(139,17): CreateGlyphSet gsid=0x03200008 format=0x00000024
-000:<:004d:108: RENDER-Request(139,20): AddGlyphs glyphset=0x03200008 glyphids=0x0000036d; glyphs={width=7 height=10 x=-1 y=10 xOff=9 yOff=0}; data=0x00,0x3e,...
+000:<:004c: 12: RENDER-Request(139,17): CreateGlyphSet gsid=0x05400008 format=0x00000026
+000:<:004d:388: RENDER-Request(139,20): AddGlyphs glyphset=0x05400008 glyphids=0x0000036d; glyphs={width=9 height=10 x=0 y=10 xOff=9 yOff=0}; data=0x00,0x00,...
（对于更多字符，宽度为 8 对 10、9 对 11 等继续进行）
所以大概是什么导致了这个问题出现在第 138 行之前的某个地方。在此之前，大多数差异似乎是用于对象的 ID 号的变化，因此找出真正的差异是有点痛苦的。
那么我看到了哪些主要差异？好吧，客户端连接后的初始响应几乎相同，除了对数（带有独立 Radeon 显卡的那个）返回更多的视觉效果。两者都以：
{id=0x00000021 class=TrueColor(0x04) bits/rgb-value=8 colormap-entries=256 red-mask=0x00ff0000 green-mask=0x0000ff00 blue-mask=0x000000ff},
{id=0x00000022 class=DirectColor(0x05) bits/rgb-value=8 colormap-entries=256 red-mask=0x00ff0000 green-mask=0x0000ff00 blue-mask=0x000000ff},
之后的列表似乎主要是重复的，只是在对数方面有更多的重复。
下一个重大区别在于Reply to QueryPictFormats：视觉列表在对数screens=... depths=... visuals={...}方面再次长得多。
但在最后还有一个更显着的区别：
-subpixels=Unknown(0x0);
+subpixels=HorizontalRGB(0x1);
之后有一个QueryFontfor fixed ，它返回一些不同的数据，看起来只是 ID，无论如何似乎只用于创建游标，因为它在此之后立即关闭。然后它似乎几乎相同（再次，模 ID，除非我错过了什么）直到第 139 行。
编辑：字体配置调试
我还尝试FC_DEBUG使用FC_DEBUG=8191 urxvt -e true 2>outputfile. 我确认以这种方式完成时宽度确实仍然不同。区分两个输出文件在 8.5 MB 的输出中仅产生以下差异的三个实例（-_idyllic ,+` 是对数）：
- rgba: 0(i)(s)
+ rgba: 1(i)(s)