Fonts 相同配置的urxvt在不同的X服务器上具有不同的宽度/字体呈现

我有两台不同的桌面主机通过其DisplayPort输出连接到同一4K监视器上的两个DisplayPort输入：

• 田园诗，一款小型PC，采用赛扬N3350处理器的内置英特尔高清图形500。（据我所知，我在另一个地方也有一个类似的系统，它有奔腾N4200处理器和Intel 505图形，在4K下运行相同。）
• 对数，一种相当通用的旧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

  在这两个文件上产生相同的输出。在两个系统上，我也有完全相同的源代码Pro字体集加载到~/.font

我可以在它们中的任何一个上启动一个80列xterm，配置为

xterm*VT100*font:-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1

，它们看起来相同，宽484像素。如果我在本地X服务器上使用

ssh-X

启动另一台机器上的xterm客户端，这一点不会改变

但是，

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

在田园诗的X服务器上显示时，无论是本地显示还是通过

ssh-X

在另一台主机上启动，垂直最大化时，80列终端宽644像素，高106列。然而，当我启动它在对数的X服务器上显示时（再次在本地或使用

ssh-X

的远程客户端），80列

urxvt

宽726像素，尽管垂直最大化时仍有106列高

因此，问题是：

是什么原因导致对数上的

urxvt

变宽，我如何使其与田园诗般的窄尺寸相同？即使您不知道，也请提供调试提示。我很乐意编写与X11服务器对话的程序（更喜欢Python或类似的程序，而不是C或类似的程序），并让我使用与

urxvt

类似的渲染，看看是否可以通过这种方式找到问题，如果您对我应该调用什么API以及我应该寻找什么样的结果有具体的建议

一个附带问题：

xft:

字体是由X客户机呈现的，对吗？如果这是正确的，那么这似乎是一个很大的提示，即X11服务器中的某些设置正在改变同一主机上的同一客户机呈现字体的方式，这取决于它与哪个X11服务器通信

编辑：

xfce4终端

信息 我试过启动一个

xfce4终端

，并将字体设置为9点源代码专业版；它在两台X11服务器上都是一样的，总是采用

urxvt

在对数上使用的更广泛的格式。这似乎表明它与

urxvt

本身有关，或者可能与

Xft

库有关（如果

xfce4终端

不使用它；我很确定

urxvt

使用它），而不是FreeType

编辑：

xtrace

信息 我从

xtrace

（谢谢你的想法，！）那里得到了更多的信息，至少让我更详细地看到了问题所在。即使只运行

xtrace urxvt-e true

也会产生几百千字节的输出，因此显然我不打算在这里全部包括这些，但这里有一些关键位。下面的差异是田园诗般的→田园诗般的→对数，即田园诗般地在两种情况下运行

urxvt

，但首先在自身上显示，其次在对数上显示

在每个

CreateWindow

调用的第156行，确认正在创建具有相同高度但不同宽度的窗口，如我前面所述（我测量了一个窗口的宽度，但其他两个像素不在）：

（对于更多字符，这将继续，宽度为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},

之后的列表似乎主要是重复的，只是在对数端有更多的重复

下一个大区别是

回复QueryPictFormats

：其中

屏幕=。。。深度=。。。visuals={…}

visuals列表的对数长度也要长得多

但在这一点的最后，还有一个更显著的区别：

-subpixels=Unknown(0x0);
+subpixels=HorizontalRGB(0x1);

在这之后，有一个用于fixed的

QueryFont

，它返回一些不同的数据，看起来就像ID一样，而且似乎只用于创建一个游标，因为它随后会立即关闭。然后，直到第139行，它看起来几乎是一样的（同样，模ID，除非我遗漏了什么）

编辑：FontConfig调试 我还尝试使用

FC_DEBUG=8191 urxvt-e true 2>outputfile

检查每台服务器。我确认，这样做时，宽度确实仍然不同。在8.5 MB的输出中，对两个输出文件进行差分只会生成以下文件的三个实例

{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},

-subpixels=Unknown(0x0);
+subpixels=HorizontalRGB(0x1);

-   rgba: 0(i)(s)
+   rgba: 1(i)(s)