Re: X Logical Font Description и HiDPI

Максим, здравствуйте.

Спасибо за ответ.

On 03.02.2021 16:30, Maksim Dmitrichenko wrote:

>     Так, любой из приведённых ниже двух запросов должен вернуть шрифт `Courier New` размером 12 pt в разрешении X-сервера:
> 
>     > -monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
>     > -monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1
>     *Или, по кр. мере, я так думал*. Штука в том, что, пересев с мониторов с разрешением в 96...115 dpi за 4k-монитор с разрешением в 162 dpi, я заметил, что мои заботливо выбранные векторные шрифты внезапно стали мелковаты.
> 
> 
> Я сильно подозреваю, что вы немножечко путаете тёплое с мягким. В ответ на такой запрос
>> -monotype-courier new-medium-r-normal--0-120-0-0-m-0-iso10646-1
> можно получить ответ о том, что такой шрифт на сервере имеется в программе типа xfontsel. Но получить автомагически шрифт в виде готовых глифов с нужным вам разрешением нельзя.

И да, и нет.

Например, утилита `xlsfonts` может работать в и режиме ListFonts/ListFontsWithInfo, и в режиме OpenFont/QueryFont (`xlsfonts -o`).
Наконец, `xfd` таки принимает на вход маску, а открывает реальный шрифт.

И поведение обеих утилит не противоречит моему предыдущему (описанному выше) опыту.


>     И выяснилось, что, если явно не указывать RESOLUTION_X и RESOLUTION_Y равными 162 (а никто в здравом уме этого не делает – это пришлось бы каждый раз при изменении монитора переписывать сотни строк Xresources), то X-сервер по умолчанию отдаёт шрифт в разрешении 100 dpi вместо 162.
> 
> 
> Что логично. Откуда он знает, что вам нужно инстанциировать глифы именно под 162, а не  под 163? Вообще я сильно подозреваю, что там не 100 dpi, а 96 dpi, поскольку в век композитных менеджеров сейчас принято, чтобы X-server плевал на какие-либо настройки, касающиеся физических размеров экрана, информации с EDID и прочее, и жестко прибивал бы 96 dpi.

С одной стороны, да.

С другой стороны, механизма, реализующего самый распространённый пользовательский сценарий и позволяющего сказать серверу "дай мне растеризованный шрифт размером 12 пунктов в твоём текущем, дорогой сервер, разрешении", как выясняется, нет. По-хорошему, X-клиент должен сначала запросить разрешение экрана у X-сервера, а уже потом в соответствии с этим разрешением сформировать маску запроса шрифта.

Но так никто не делает (кроме, пожалуй, старого Netscape 4.x и ранних версий Mozilla, использовавших серверные шрифты).

Что сводит на нет всю потенциальную пользу от X-ресурсов.


К слову о 96 dpi -- я тоже об этом думал (хотя бы потому, что это значение "зашито" в API FreeType), но нет.
Там таки 100 dpi:

> $ xlsfonts -ll -o -fn '-monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1'
> name:  -monotype-courier new-medium-r-normal--*-120-*-*-m-*-iso10646-1
>   direction:            left to right
>   indexing:             matrix
>   rows:                 0x00 thru 0xff (0 thru 255)
>   columns:              0x00 thru 0xff (0 thru 255)
>   all chars exist:      no
>   default char:         0x0000 (0)
>   ascent:               17
>   descent:              12
>   font type:            Character Cell
>   bounds:               width left  right  asc  desc   attr   keysym
>         min               10    -2    10    15     5  0x0259
>         max               10     8    10    17    12  0x27db
>   properties:           36
>       FONT                  -monotype-courier new-medium-r-normal--17-120-100-100-m-100-iso10646-1
>       FOUNDRY               monotype
>       FAMILY_NAME           courier new
>       WEIGHT_NAME           medium
>       SLANT                 r
>       SETWIDTH_NAME         normal
>       ADD_STYLE_NAME        
>       PIXEL_SIZE            17
>       POINT_SIZE            120
>       RESOLUTION_X          100
>       RESOLUTION_Y          100
>       SPACING               m
>       AVERAGE_WIDTH         100
>       CHARSET_REGISTRY      iso10646
>       CHARSET_ENCODING      1
>       RAW_PIXEL_SIZE        1000
>       RAW_POINT_SIZE        723
>       RAW_AVERAGE_WIDTH     6001
>       FONT_ASCENT           17
>       RAW_ASCENT            832
>       FONT_DESCENT          12
>       RAW_DESCENT           300
>       FACE_NAME             Courier New
>       _ADOBE_POSTSCRIPT_FONTNAME CourierNewPSMT
>       SUBSCRIPT_SIZE        11
>       SUBSCRIPT_X           0
>       SUBSCRIPT_Y           2
>       SUPERSCRIPT_SIZE      11
>       SUPERSCRIPT_X         0
>       SUPERSCRIPT_Y         7
>       UNDERLINE_THICKNESS   1
>       UNDERLINE_POSITION    4
>       ITALIC_ANGLE          5760
>       FONT_TYPE             TrueType
>       RASTERIZER_NAME       FreeType


По здравом размышлении прихожу к выводу, что схема XLFD сама по себе ущербна.

Дело в том, что X-ресурсы (речь в первую очередь о шрифтах) для каждой конкретной программы могут существовать как на стороне сервера (всё то, что даётся на вход `xrdb`), так и на стороне клиента (см. `XUSERFILESEARCHPATH`). И настройки, скажем, шрифта для пресловутого `xterm` должны храниться где-то в одном месте -- либо на клиенте, либо на сервере. А XLFD (и вот это как раз-таки и неправильно!) включает в себя и серверные параметры (`RESOLUTION_X` и `RESOLUTION_Y`), и клиентские (`CHARSET_REGISTRY` и `CHARSET_ENCODING` – ведь потенциально удалённый, "сетевой" X-клиент может быть запущен в окружении и с региональными настройками, отличными от окружения и настроек X-сервера).

При разработке Xft Кит Пакард, видимо, учёл недостатки такого подхода и наконец всё сделал по уму: имя и размер шрифта в пунктах (`DejaVu Sans Mono:size=12`) задаёт X-клиент, а X-ресурс `Xft.dpi` является частью состояния X-сервера.

Но всё вышенаписанное не отменяет моего исходного вопроса =)

Можете как-л. прокомментировать?

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSk78qvEH59Jewf+OAVfbB6hOsMZwUCYBq7jgAKCRAVfbB6hOsM
Z78nAJ9hrQpA45U4zmbUO9CzBi/wIFUWSwCg4Lfd3vI25ROunFID5aqeqxXw7hs=
=RMDF
-----END PGP SIGNATURE-----