Рендеринг шрифтов в X Window: как в MS Windows и даже лучше

Владимир Попов
2007.02.19
Впервые опубликовано: LinuxFormat, 2006, 79

Оригинал: posix.ru

Вместо предисловия

Данная статья — ещё одна попытка помочь сделать десктоп *-nix систем более привлекательным. Нынешние KDE или Gnome предлагают десятки стилей оформления окон, эффекты анимирования, плавного исчезновения, полупрозрачности и теней, а нарекания на внешний вид X Window по-прежнему не редки. В большой степени, как мне кажется, это определяется качеством рендеринга (прорисовки) шрифтов. Так ли плоха сама система рендеринга? Нормально ли, что одни и те же параметры можно задавать на уровне X Window, менеджера входа в систему, window-менеджера и, наконец, отдельного приложения? И как с этим бороться?

Не буду пытаться советовать, как сделать именно "красиво", только постараюсь обратить внимание на некоторые технические аспекты рендеринга в надежде на то что кому-то это поможет средствами KDE или Gnome создать десктоп, о котором можно будет сказать, что он действительно "как в MS Windows или лучше".

Давным-давно...

Лет пятнадцать назад в беседе с одной американской знакомой, впервые доставившей в Москву персональные компьютеры с процессором DEC-Alpha, я услышал такую фразу: "Хочу привезти компьютеры с UNIX, чтобы вы увидели настоящую графику". О достоинствах UNIX в качестве серверной платформы я на тот момент знал достаточно, а вот о том, что её сильная сторона — графика, услышал впервые. После терминалов IBM 360 и PDP-11, после DOS и Norton Commander-a, графическая оболочка Windows NT, запущенная на этих самым Alpha-х, казалась едва ли не верхом совершенства. Признаться, я усомнился в правоте своей знакомой, но, оказалось, напрасно.

В те далёкие времена АРМ-ы, сделанные на UNIX (будь-то рабочее место раскройщика кожи или тренажёр космонавта), действительно выглядели более презентабельно, чем MS Windows, делавшая тогда лишь первые шаги. Шли годы, персональные компьютеры теснили мини-ЭВМ и мэйнфреймы, как млекопитающие динозавров, а вслед за ними и MS Windows становилась всё более популярной, тогда как о UNIX применительно к IBM PC сказать было нечего: её просто не было. Положение изменилось с появлением Linux. Идеи и наработки, накопленные за годы существования UNIX, стали постепенно находить себе место и на персональных компьютерах.

Оставим в стороне принципиальные различия между миром open source и проприетарным ПО. Сосредоточимся на графической оболочке nix-ов. Как известно, все они используют open source реализацию X Window System. По определению X.Org Foundation, X Window — это "прозрачная" сетевая система оконного типа, функционирующая на разнообразных вычислительных системах и столь же разнообразном графическом оборудовании. То есть: не только оболочка, не только для Linux и не только на IBM PC.

И это действительно так. Впечатляющие по своей экономичности клиент-серверные системы, в которых OpenOffice, Mozilla и Gimp успешно работают на станциях с Pentium-166 и 64МБ RAM — отличная тому иллюстрация. Серверные возможности X Window впечатляют, и трудно поверить в то, что в рамках того же проекта рендеринг шрифтов решён так безобразно, как можно предположить, выслушивая уничтожающие отзывы некоторых пользователей, сравнивающих десктоп Linux с десктопом Windows XP (с чем же ещё сравнивать?). С одной стороны, я беру на себя смелость защищать разработчиков X Window, а с другой — признаю, что для недовольства "простого" пользователя имеется подчас достаточно оснований. Ниже следует перечисление этих оснований с последующим предложением способа исправления ситуации.

libfreetype

Вообще-то не совсем справедливо, когда от X Window требуют, чтобы было не просто хорошо, а именно "так, как в XP". Реальность, однако, именно такова. И формулировка "как в MS Windows или лучше" (Like MS Windows, even better) достаточно точно отражает и характер, и уровень требований.

Прежде всего, это значит, что речь идёт о True-Type фонтах. Вывод растровых фонтов давно уже не является проблемой, а использование свободных масштабируемых фонтов, традиционно входящих в состав X Window, как бы совершенна ни была их прорисовка, оставляет пользователю, привычному к виду Windows-декстопа, основания быть недовольным. "Сила привычки" определяет его отношение, или фонты из состава X Window действительно так уступают Arial/Tahoma/Verdana/Trebuchet — не суть важно. Не будем также касаться правомерности использования ttf-фонтов из состава MS Windows. Зададимся иным вопросом: можно ли в X Window видеть их такими же, как в XP? Если "в принципе — да", то почему "буковки — меньше и вообще как-то "аляповато"?

W/o BYTECODE_INTERPRETER Option

Первым и самым главным (в случае его наличия) недостатком является компиляция библиотеки libfreetype без опции TT_CONFIG_OPTION_BYTECODE_INTERPRETER. Cуществуют патентные ограничения на использования этого самого BYTECODE_INTERPRETER: патент принадлежит Apple, а действует ли он там, где может оказаться libfreetype, разработчики, разумеется, не знают. Так что и в версии freetype-2.1.10 (последней стабильной на начало 2006-го года) в файле include/config/ftoption.h опция TT_CONFIG_OPTION_BYTECODE_INTERPRETER не определена. Для незнакомых с синтаксисом include-файлов укажем, что файл ftoption.h должен содержать строку:

#define TT_CONFIG_OPTION_BYTECODE_INTERPRETER

Исходники библиотеки можно взять на freetype.sourceforge.net. Желаемое местонахождение библиотек нужно указать в команде конфигурации, например:

./configure --prefix=/usr

если файлы должны оказаться в каталоге /usr/lib.
Компиляция запускается посредством make, инсталляция — make install.
Инсталляцию, в принципе, можно и не делать. Достаточно после компиляции переписать файлы libfreetype.a, libfreetype.la и libfreetype.so.6.3.8 (для последнего файла в вашем случае версия, разумеется, может быть иной) в нужный каталог. Для прекомпилированного дистрибутива такое решение даже предпочтительней: базу данных установленных пакетов редактировать не придётся. Если компилировалась версия libfreetype,отличная от той, что была установлена в вашей системе ранее, то можно переписать каталог include/ и конфигурационный файл freetype2.pc. "Можно", а не "нужно", поскольку если вы "простой пользователь", то include/ и freetype2.pc вам, скорее всего не понадобятся. Если же "прелести самосборки" вам не безразличны, то вы это и сами знаете — также как и то, что после установки новых библиотек рекомендуется запускать ldconfig.

DPI

Когда с libfreetype будет всё в порядке, а десктоп перестанет вызывать острую жалость, можно перейти к следующему шагу и попытаться ответить на вопрос: почему один и тот же фонт, одного и того же кегля кажется имеющим разный размер под XP и X Window?

W/i BYTECODE_INTERPRETER Option

Дело в том, что ключевым параметром при создании векторных изображений является так называемый DPI — "dot-per-inch", который говорит о том, сколько точек (пикселей) помещается на экране в отрезке длиной дюйм. Казалось бы: разрешение известно, физический размер экрана — тоже, какие трудности? Тем более, что современные мониторы по запросу выдают блок информации, в котором могут присутствовать данные и о физических размерах экрана. И даже не так важно, что ещё "живы" мониторы, понятия не имеющие о том, что такое DDC, как то, насколько значение dpi, рассчитанное таким образом, обеспечит качественный рендеринг масштабируемых фонтов.

Актуальное значение dpi всегда можно узнать, набрав в терминальном окне:

xdpyinfo | grep resolution

Не так давно считалось, что достаточно двух значений dpi: 75 и 100. 75 — для вывода мелким шрифтом и 100 — крупным. Об этом до сих пор напоминают названия каталогов: /usr/X11R6/lib/fonts/75dpi и /usr/X11R6/lib/fonts/100dpi.

В то же время, пользователи MS Windows знают, что им по умолчанию предлагается три размера шрифтов: малый, нормальный и большой (масштаб 72, 96 и 120 dpi соответственно). Истоки различий значений по умолчанию я объяснить не могу. Не исключено, что они связаны с алгоритмами растеризации совершенно определённых фонтов. Во всяком случае, неоднократно отмечалась связь качества рендеринга ttf-фонтов с кратностью задаваемого dpi 6-ти и даже 12-ти. Так или иначе, но произвольные значения dpi, которые MS Windows позволяет устанавливать, воспользовавшись "custom" масштабом, достаточно часто приводят к заметному ухудшению отображения. Отметим пока эти три числа и вернёмся к X Window.

Воспользовавшись вышеупомянутой утилитой, можно узнать, каким полагает X Window размер экрана:

xdpyinfo | grep dimension

Выведенное в ответ разрешение экрана не удивляет (сами ведь задавали), размер экрана в миллиметрах получен, очевидно, от монитора, но вот насколько расчитанный dpi соответствует лучшему рендерингу?

Поскольку в документации X Window рекомендаций по этому поводу найти не удалось (да и какой линуксоид не предпочтёт собственные эксперименты чтению документации?), впору перейти к описанию способов задания dpi. Итак:

Во всех перечисленных случаях NN — значение dpi. Что же касается того, каким должно быть это значение, то единого мнения нет. Никто не мешает поэкспериментировать, но если имеет место дефицит времени и желание воспользоваться "советами старых мастеров", то попробуйте dpi=75 или 100 для фонтов из состава X Window, и наоборот — при "равнении" на MS Windows придерживайтесь ею же рекомендуемых значений.

W/i DPI=96

Xft

Из двух систем, занимающихся визуализацией шрифтов в X Window, нас, безусловно интересует Xft, поскольку речь идёт исключительно о масштабируемых фонтах. Незатейливое xft-config --libs сообщает, что в состав подсистемы, кроме Х-овых библиотек Xft, X11 и Xrender входит уже известная нам библиотека freetype и неизвестная пока fontconfig.

Дело в том, что Xft, не имея собственных средств конфигурации, для задания характеристик шрифтов и параметров растеризации использует библиотеку fontconfig. А интерфейсом к ней являются файлы /etc/fonts/fonts.conf, /etc/fonts/fonts.dtd и ~/.fonts.conf. Вот бы и закончить обсуждение настройки Xft описанием этих файлов, сославшись не пресловутое 'man fonts-conf'...

К сожалению, не получится. Хотя все современные win-менеджеры по умолчанию используют Xft, параметры рендеринга они задают самостоятельно. При этом в "Центре управления KDE" или "Настройках шрифтов Gnome" прямых аналогий параметрам fontconfig может и не быть, хотя в целом соответствие найти не трудно. Параметры эти следующие:

Возможности настройки fontconfig намного шире предлагаемых KDE/Gnome, поскольку позволяют задавать параметры для семейств шрифтов, отдельного фонта, диапазона кеглей и даже определённого значения кегля. Типичный пример: отключение сглаживания для малых кеглей или, напротив, включение для всех фонтов семейства Vera. Вопрос только в том, захотите ли вы этим заниматься, тем более, если используете KDE, также позволяющий ограничивать сглаживание для диапазона кеглей. С другой стороны, к достоинствам Gnome следует безусловно отнести возможность "на ходу" менять dpi, моментально оценивая результат для конкретного фонта и параметров сглаживания.

Насколько антиалиасинг улучшает вид текста, набранного сравнительно большим кеглем (текст страницы) и насколько, в то же время, он может быть неуместен (меню и панель навигации), демонстрирует следующий скриншот:

W/i antialiasing

Из возможностей, предоставляемых исключительно fontconfig, стоит отметить задание состава семейства шрифтов. Обращаясь к услугам Xft, приложению, вообще говоря, совсем не обязательно указывать определённо существующий фонт. Можно требовать, скажем, sans-serif — и какой-то фонт из этого семейства Xft вам обязательно предоставит. А вот какой — определяется описанием этого семейства, выглядящим, например, так:

<alias> <family>sans-serif</family> <prefer> <family>Tahoma</family> <family>Verdana</family> <family>Helvetica</family> </prefer> </alias>

Поскольку синтаксис xml и тонкости fontconfig явно выходят за рамки статьи, приходится адресовать интересующихся к уже упомянутому 'man fonts-conf' и поиску в Сети по ключевым словам fontconfig или fonts.conf.

Фонты и кегли

Чисто "техническая" сторона борьбы за лучший рендеринг после исправления libfreetype и выбора dpi заканчивается: выбор фонтов, кеглей и параметров можно назвать сферой, где "на вкус и цвет товарищей нет". Поскольку "единого мнения" ожидать не приходится, хорошо бы договориться хотя бы о терминах.

Прежде всего о кеглях. С учётом вышесказанного по поводу dpi, очевидно, что размер на экране одной и той же "Tahoma 8" при dpi=75 и при dpi=120 будет различаться без малого в два раза, из чего следует, что нахваливая (или, напротив, уничтожающе критикуя) использование кегля определённого фонта, всегда нужно указывать dpi.

Во-вторых, восприятие одних и тех же фонтов на экранах ЭЛТ и LCD мониторов существенно отличается. Для последних нелишним будет оговорить, что монитор работает с рекомендованным разрешением (а оно у LCD только одно), а о работе ЭЛТ нельзя судить без указания частоты кадровой развёртки (refresh).

Механизмы рендеринга MS Windows и X Window не идентичны. С учётом варьирования dpi и зависимости от этого отображения различных фонтов, нет смысла гнаться за полной идентичностью десктопов. Некоторые ttf-фонты при особо малых кеглях могут вообще демонстрировать дефекты начертания, отсутствующие в MS Windows. Это, однако, исключение. В большинстве случаев при "прочих равных условиях" (dpi, сглаживание (в MS Windows это называется "method to smoth edges of screen fonts", выбор между "Standard" и "ClearType". Причём последний соответствует включённому сглаживанию), палитра, фонт, кегль) десктопы обеих графических сред весьма схожи.

При этом, однако, запуск различных приложений под X Window опять-таки время от времени приносит болезненное разочарование. Причём, ещё до анализа отдельных приложений, несколько слов придётся сказать о графических тулкитах — наборах библиотек, средствами которых реализуется графический интерфейс как отдельных приложений, так и "графических сред", таких как KDE или Gnome.

Gtk/Qt

В настоящее время большая часть графических приложений создаётся с использованием Qt (KDE, Opera) или Gtk (Gnome, Gimp, Mozilla). Они не единственные, но "заслуженный" Tk им не конкурент уже, а оригинальный Fltk — ещё. Поскольку использование Qt не обязательно предполагает KDE, а Gtk — Gnome, то естественно предположить, что должны существовать возможности настройки для приложений, которые используют названные тулкиты вне KDE/Gnome. И такие средства есть: для Qt это ~/.qt/qtrc, для Gtk — ~/.gtkrc-2.0.

В qtrc вы можете обнаружить строку разрешения работы Xft, фонт "по умолчанию", стиль и подробное описание палитр. Что касается gtkrc-2.0, то его может вообще не быть: в отличие от KDE, создающего qtrc при первом запуске, Gnome возможность существования gtkrc-2.0 игнорирует. А создать такой файл бывает очень полезно, потому как "не всё то Gnome, что на Gtk написано".

Вообще, одновременное использование приложений, базирующихся на двух и более тулкитах, изящества десктопу не прибавляет: элементы одного назначения, но разного внешнего вида вряд ли кому-то нравятся. Не стремимся же мы к индивидуальному декорированию окон: win-менеждер может быть любой, но стиль отображения окон — всегда "один на всех". Реальность, однако, такова, что приверженцы KDE/Gnome испытывают друг к другу если не неприязнь, то сожаление, и при этом существует ряд приложений, применяемых и теми, и другими. Прежде всего, это Open Office, Gimp, Mozilla "с потомками", ROX Filer и т.д.

Как может выглядеть приложение, использующее не тщательно подобранные вами в "Центре управления KDE" фонты и кегли, а что-то совершенно "чуждое"? В большинстве случаев — плохо. Чтобы этого не было, укажите в gtkrc-2.0 фонт и кегль те же, что используете в качестве "обычного" или "меню". Например:

gtk-font-name = "Tahoma 8"

Final

Элементы управления схожими не станут, но ROX с Firefox-ом в рамках KDE глаз станут резать меньше. Пользователи Gnome аналогичным образом могли бы поступить с qtrc, но Qt-приложений, незаменимых в среде Gnome я, практически, не знаю.

Раз уж мы уделили столько внимания конфигурационным файлам, то укажем ещё два: ~/.gconf/desktop/gnome/font_rendering/%gconf.xml и ~/.kde/share/config/kdeglobals. "Пути" к ним однозначно указывают на то, что именно они конфигурируют, а в содержимом без труда угадываются "прямые потомки" параметров, обсуждавшихся выше.

Firefox, thunderbird и другие

К сожалению, и после настройки конфигурации любимой среды и, одновременно, приложений, использующих "чуждый" тулкит, мы не застрахованы от появления на экране приложений с неудовлетворительно прорисованным текстом. Оставим в стороне графические пакеты: те, кто работает с графикой сами должны знать, что такое dpi и не только на экране... Не стоит обсуждать также фонты и кегль, которые приложение позволяет настроить: это, в сущности, ваше личное дело. Но что делать со слишком большими/маленькими или просто "корявыми" фонтами в панелях, меню, подсказках?

В качестве примера предлагаю настроить Firefox (или любого другого "потомка" mozilla). Среди настроек "Шрифты и цвета", кроме задания фонтов и размеров, которые мы решили не обсуждать, имеется pop-up меню "Разрешение экрана". Как вы, вероятно, догадываетесь, никакое разрешение экрана Firefox не меняет, а меняет лишь многократно упоминавшийся dpi. Поскольку dpi, как мы выяснили, — весьма "капризный" параметр, то если вы уж определили его для себя, то и Firefox заставьте придерживаться того же значения (выбор: "Системные настройки").

mozilla и все её потомки — Gtk-приложения. Поэтому, если вы — приверженец KDE и ещё не создали ~/gtkrc-2.0 то перед запуском Firefox самое время вспомнить об этом. Именно gtk-font "по умолчанию" использует Firefox в окне "Настройки". Если же один фонт в панелях, меню и на кнопках вас не устраивает, то придётся прибегнуть к редактированию файла под названием ~/.mozilla/firefox/XXXX.default/chrome/userChrome.css. Такого, правда, поначалу может и не быть, но заготовка для него под названием userChrome-example.css — имеется. Вот как задаётся шрифт большей части элементов интерфейса:

menubar, menubutton, menulist, menu, menuitem { font-family: "Tahoma" !important; font-size: 8pt !important; }

Tahoma, в данном случае, указана не из-за каких-то её особых достоинств, а исключительно потому, что в соответствии с приведенными выше примерами именно её мы выбрали в качестве "первого"представителя семейства "serif", фонта приложений и фонта "по умолчанию" для Gtk-приложений. Подобного единообразия рекомендую придерживаться и вам.

!important указывает на приоритет настройки относительно умолчаний. Более подробно о возможностях userChrome.css можно прочитать в http://www.mozilla.org/unix/customizing.html. Подобным образом userContent.css задаёт параметры вывода просматриваемых страниц. Однако, поскольку параметры вывода текста этих страниц можно менять и через "Настройки", то мало кто этим пользуется.

И снова: не обольщайтесь. Авторы тем тоже знают, что такое каскадные таблицы стилей, и однажды поменяв тему, вы можете обнаружить, что фонты опять вас не устраивают. Обсуждение использования css-файлов в mozilla, опять-таки, — не тема настоящей статьи.

Итоги

Так могут ли шрифты под X Window выглядеть лучше, чем под XP? Наверное, иногда действительно могут, поскольку возможностей для "тонкой" настройки рендеринга X Window предоставляет явно больше. Разнообразие возможностей, однако, хотя и является источником прогресса, всегда способствует поддержанию некоторого уровня беспорядка (и это ещё мягко сказано). Приятное же глазу единообразие создать можете либо вы сами, либо ментейнер вашего дистрибутива. Причём во втором случае, как ментейнер должен обеспечить унифицированность настроек предлагаемых им приложений, так и вам рекомендуется использовать пакеты исключительно своего дистрибутива.

Настойчивый и компетентный пользователь всегда может добиться желаемого результата. С другой стороны, Linux-хиты последнего времени, такие как Ubuntu/Kubuntu, выглядят в сравнении с XP вполне достойно. Будем надеяться, что и впредь программисты X.Org будут развивать систему, используемую в качестве основы для различных моделей десктопов. Разработчики графических сред смогут предложить исчерпывающе полные реализации "пользовательских окружений". А составители дистрибутивов постараются избавить "простых" пользователей от многочисленных настроек — с одной стороны, и разочарований при сравнении с Windows XP — с другой.

Так что там за ttf?

Многообразие существующих ныне ttf-фонтов описанию не поддаётся. Если, однако, исключить сугубо "декоративные", да ещё не содержащие символов кириллицы, то число это существенно уменьшится. При сравнении же c MS Windows и вовсе подразумевается вполне определённый набор — так называемый mscorefonts, куда помимо 'arial', 'courier new' и 'times new roman' от monotype входят и наиболее известные фонты MicroSoft: 'verdana', 'tahoma', 'trebuchet' и т.д. Если непосредственно с microsoft.com загрузить эти фонты не удастся, то рекомендуется воспользоваться альтернативой: http://corefonts.sourceforge.net. Существующая лицензия не запрещает использование фонтов в некоммерческих целях. Исключением является 'tahoma'. Тут придётся считаться с ограничениями IE EULA, главное из которых состоит в том, что хоть какую-то лицензию на использование IE иметь вы должны. Что же касается запрета на модификацию файлов, то придётся к пяти мегабайтам фонтов прибавить ещё и утилиту cabextractMicroSoft не жалует общепринятые средства архивирования.

Pango, Cairo и т.д.

Рендеринг текста на выводе символов не заканчивается, как нетрудно догадаться. Символы складываются в слова, слова в блоки и т.д. Форматирование текста, вопросы интернационализации... всё это уже "вне компетенции" Xft. В GTK+ 2, например, за это отвечает библиотека Pango. В связи с начертанием отдельных символов на этом можно бы и не останавливаться (абсолютное большинство дистрибутивов в настоящее время включают версию Pango, использующую для рендеринга Xft), но альтернатива уже существует: Cairo. Эта новая библиотека, как и её предшественницы, обеспечивает единый подход в реализации векторной графики на всех устройствах отображения, но при этом использует преимущества аппаратной акселерации при выводе на экран. GTK+ 2.8 уже включает поддержку Cairo и очень скоро мы сможем оценить её достоинства.

А как "у них"?

MicroSoft не балует своих пользователей множественными настройками рендеринга, но количество недовольных этим, надо признать, весьма невелико. Вооружившись "увеличительным стеклом" можно попытаться выяснить, в чём же состоят эти "умолчания", устраивающие большинство. На основании личных наблюдений это:

Сказанное не означает, перечисленные настройки — лучшие. Но, то, что они устраивают не один миллион пользователей — факт.

А что, собственно, меряем?

Размер шрифта, как и любая другая величина, измеряется в определённых единицах. Неудобство доставляет не столько разнообразие этих единиц (ну что ж поделаешь, если часть мира предпочитает метрическую систему измерения, а часть — английскую), как то, что часть из них абсолютна, а часть — относительна. Поскольку размер писксела (px) определяется разрешением и геометрическими размерами экрана, то это величина относительная, ну а абсолютность метра (сантиметра, дюйма) сомнений не вызывает. Таким же абсолютным является и типографский пункт (pt), составляющий приблизительно 0.35mm. Размер в пунктах — численно наиболее близок к размеру в пикселах при "нормальном" разрешении, однако путать их всё же не следует. Первый, как правило, меньше, Ну, а если речь о экране PDA или, напротив, 50-ти дюймовой плазменной панели, то соответствия пунктов пикселам ожидать не приходится.