[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

X, xrdb, xrandr



>>>>> Artem Chuprina <ran@lasgalen.net> writes:

[…]

 > А теперь призовая игра.  Она, кстати, не только для xrdb призовая, и
 > более того, может оказаться, что для гнома она окажется на порядок
 > более призовой.  А может и нет, вопрос в том, в каких единицах оно
 > поймет шрифт.  Но для xrdb оно точно призовое.  Допустим, у нас два,
 > а лучше три одновременно подключенных монитора, и по
 > жабно-историческим причинам у них X_RESOLUTION и Y_RESOLUTION разные.
 > Было бы клево, чтобы размер шрифта был на обоих мониторах одинаковый
 > хотя бы в линейных единицах (в идеале, конечно, угловых, но вот
 > данных о расстоянии от глаз до монитора у нас точно нет — зато есть
 > неплохие шансы, что оно близкое).  А вовсе не в пикселах, которые по
 > размеру могут отличаться в полтора раза с легкостью.

	Не в пикселах?  Почему бы и нет.

XClock.face: courier-14.0
UXTerm.vt100.faceName: courier
UXTerm.vt100.faceSize: 14.0
!! etc.

	Будет ли это работать с несколькими физическими мониторами,
	соответствующими одному X display — не знаю.  Но при запуске
	после $ xrandr --dpi XXX — желаемый эффект наблюдается.

	Есть также подозрение, что такое поведение можно обеспечить и
	при использовании «классических» X-шрифтов (e. g., ниже.)
	Другое дело, что в базе данных (растровый) шрифт нужного кегля
	почти наверняка окажется представлен одной—двумя записями
	(например, 75 и 100 dpi.)

!! Use a suitable 20pt Terminus font
UXTerm.vt100.font:  -xos4-terminus-medium-r-normal--*-200-*-*-c-*-iso10646-1

$ xlsfonts -fn "-xos4-terminus-medium-r-normal--*-200-*-*-*-*-iso10646-1" 
-xos4-terminus-medium-r-normal--20-200-72-72-c-100-iso10646-1
-xos4-terminus-medium-r-normal--28-200-100-100-c-0-iso10646-1
$ 

 > Опять же в идеале программа должна бы уметь перестраивать шрифт при
 > попадании с одного экрана на другой, даже если ее саму при этом
 > никуда не таскали (ситуация «вывел workspace N на второй экран»).  Но
 > на этом я уже не настаиваю от слова совсем.  Это уже очень хорошие
 > программисты нужны.

	JFTR, X-ресурсы предназначены для решения частной задачи передачи
	настроек от пользователя X-приложениям.  Причем под настройками
	понимаются пары (ключ, значение) и (шаблон, значение).  С этой
	задачей X-ресурсы как будто бы худо-бедно справляются.
	(Пользуясь случаем напомню, что у «Tk-ресурсов» в кортеж входит
	еще и priority.  X-ресурсам оный бы тоже не повредил, но — увы.)

	Далее, есть libXt, которая, в числе прочего, включает поддержку
	некоторого количества типовых ключей и форматов значений.
	Использование этой библиотеки, однако, не является ни необходимым
	для поддержки механизма X-ресурсов (Tk обходится без нее, IIRC),
	ни достаточным для обеспечения желаемых функций.  (Вроде Xft.)

	Другими словами, то, что libXt поддерживает .geometry: и .font:,
	но не (AIUI) .faceSize: еще не означает, что «классическое»
	X-приложение обречено на использование одних лишь «стандартных»
	ресурсов.

 > Есть и другая задача, где надо одинаково в долях размера экрана.  Это
 > когда один экран у тебя, а другой у проектора, и на них одно и то же.

	Рискну предположить, что задачу отображения одного framebuffer
	на два экрана разного разрешения в общем случае окажется проще
	решить используя xrandr(1) (а именно — --scale=; или же и вовсе
	--transform=.)

-- 
FSF associate member #7257  np. Heartland (tranciano remix) — Chronblom

Reply to: