У одинаково настроенного urxvt разная ширина / рендеринг шрифтов на разных X-серверах

Question

У меня есть два разных хост-компьютера, подключенных через их выходы DisplayPort к двум входам DisplayPort на одном мониторе 4K:

• Идиллический ПК малого форм-фактора, использующий встроенную Intel HD Graphics 500 от своего процессора Celeron N3350. (У меня также есть аналогичная система в другом месте с процессором Pentium N4200 и графикой Intel 505, которая, насколько я могу судить, работает одинаково на 4K).
• логарифмическая, довольно типичная старая система ATX с процессором Intel i5-3450 и графической картой ATI Radeon 7870

Обе системы работают в полностью обновленном Debian 9 и настроены так же, как я могу управлять. Особенно:

• DPI сервера X равен 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, загруженных в ~/.fonts на обеих системах.

На любом из них я могу запустить xterm с 80 столбцами, настроенный с XTerm*VT100*font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 и они выглядят одинаково и имеют ширину 484 пикселей. Это не изменится, если я запускаю клиент xterm на другом компьютере, отображающемся на локальном 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 для отображения на X-сервере Idyllic, локально или запущенном на другом хосте с ssh -X терминал из 80 столбцов имеет ширину 644 пикселя и высоту 106 столбцов при максимальном увеличении по вертикали. Тем не менее, когда я запускаю его для отображения на логарифмическом X-сервере (снова либо локально, либо с помощью удаленного клиента с помощью ssh -X), столбец 80 urxvt имеет ширину 726 пикселей, хотя по-прежнему 106 столбцов при максимальном увеличении по вертикали.

Итак, вопрос:

Что вызывает urxvt на логарифмическом, чтобы быть шире, и как мне сделать его такой же хороший узкий размер, как и идиллический? Даже если вы не знаете, советы по отладке приветствуются. Я счастлив писать программы (предпочитая Python или аналогичные над C или аналогичными), которые общаются с серверами X11 и позволяют мне поиграть с тем же рендерингом, что и urxvt пытается выяснить, может ли проблема быть найдена таким образом, если у вас есть конкретные предложения о том, какие API мне следует вызывать и какие результаты мне нужно искать.

Дополнительный вопрос: xft: шрифты отображаются X-клиентом, верно? Если это правильно, может показаться большим намеком на то, что некоторые настройки на сервере X11 изменяют способ отображения шрифтов одним и тем же клиентом на том же хосте в зависимости от того, с каким сервером X11 он общается.

РЕДАКТИРОВАТЬ: xfce4-terminal Информация

Я пытался запустить xfce4-terminal и установка шрифта на 9 пунктов исходного кода Pro среды; он одинаков на обоих серверах X11, всегда в более широком формате, который urxvt использует по логарифмической. Это, кажется, указывает на то, что это как-то связано с urxvt сам или, возможно, Xft библиотека (если xfce4-terminal не использует это; Я уверен, что urxvt делает), а не FreeType?

РЕДАКТИРОВАТЬ: xtrace Информация

У меня есть дополнительная информация от xtrace (спасибо за идею, Uli Schlachter!), которая, по крайней мере, позволяет мне увидеть, что что-то идет не так, более подробно. Работает даже просто xtrace urxvt -e true производит несколько сотен килобайт выходных данных, так что, очевидно, я не собираюсь включать все это здесь, но вот некоторые ключевые биты. Ниже приведены различия между сеансами: идиллический → идиллический и идиллический → логарифмический, т.е. urxvt в обоих случаях, но отображается сначала сам по себе, а второй удаленно в логарифмическом.

В строке 156 в каждом CreateWindow call подтверждает, что окна создаются с одинаковой высотой, но разной ширины, как я уже упоминал выше (я измерил одно окно шириной, но остальные два пикселя вышли):

-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 каждого я вижу этот diff (вторая строка урезана для здравомыслия), который, кажется, подтверждает, с 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. С учетом того, что большинство различий, похоже, являются изменениями в идентификационных номерах, используемых для объектов, так что немного больно выяснить, что такое настоящие разницы.

Итак, какие основные различия я вижу? Что ж, первоначальный ответ после подключения клиента практически идентичен, за исключением того, что логарифмический (тот, что с дискретной видеокартой 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);

После этого есть QueryFont для fixed, который возвращает некоторые отличающиеся данные, которые выглядят как просто идентификаторы, и в любом случае кажется, что используется только для создания курсора, так как он сразу же закрывается. Затем все идет и кажется почти одинаковым (опять же, по модулю идентификаторов, если я что-то не пропустил) до строки 139.

РЕДАКТИРОВАТЬ: FontConfig Отладка

Я также пытался проверить FC_DEBUG против каждого сервера с FC_DEBUG=8191 urxvt -e true 2>outputfile, Я подтвердил, что ширина действительно все еще отличается, когда сделано таким образом. Различие двух выходных файлов дает в 8,5 МБ выходных данных только три экземпляра следующего различия (- это _idyllic , + `является логарифмическим):

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

Answer 1

Проблема заключается в субпиксельном рендеринге Xft/FreeType, который, как и в некоторых других настройках, может существенно повлиять на ширину отображаемых шрифтов, не изменяя высоту вообще.

Отладка FontConfig проясняет, что настройка рендеринга субпикселя отличается. Если установить это явно в ресурсах X, обе системы будут работать одинаково:

• Xft.rgba: rgb сделает обе системы более широкими для визуализации шрифта на обоих серверах X11 (так, как они это делают, когда любая из них рендерится в логарифмический без этого набора)
• Xft.rgba: none сделает обе системы визуализирующими шрифт на обоих серверах X11 (так, как они это делают, когда любая из них рендерится в идиллический без этого набора)

Таким образом, добавляя Xft.rgba: none к ~/.Xresources устраняет проблему

в то время как этот ответ в настоящее время является общепринятым, поскольку он решает проблему, я был бы очень рад принять другой ответ, который дает более глубокое объяснение того, что здесь происходит.