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

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

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-сервера.

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

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

Attachment: signature.asc
Description: OpenPGP digital signature

Ответить