LXF79:Шрифты «как в Windows»
|
|
|
В Сети можно найти множество рецептов облагораживания шрифтового хозяйства Linux. Владимир Попов предлагает целостный взгляд на эту проблему.
Эта статья – ещё одна попытка помочь сделать рабочий стол *nix-систем более привлекательным. Нынешние KDE или Gnome предлагают десятки стилей оформления окон, эффекты анимирования, плавного исчезновения, полупрозрачности и теней, а нарекания на внешний вид X Window по-прежнему нередки. В большой степени, как мне кажется, это определяется качеством рендеринга (прорисовки) шрифтов. Так ли плоха сама система рендеринга? Нормально ли, что одни и те же параметры можно задавать на уровне X Window, менеджера входа в систему, оконного менеджера и, наконец, отдельного приложения? И как с этим бороться?
Не буду пытаться советовать, как именно «сделать красиво». Постараюсь лишь обратить внимание на некоторые технические аспекты рендеринга – в надежде на то, что кому-то это поможет создать рабочий стол на базе KDE или Gnome, о котором можно будет сказать: «Да, он действительно как в MS Windows или лучше».
Содержание |
Давным-давно...
Лет пятнадцать назад, беседуя с одной американской знакомой, впервые доставившей в Москву персональные компьютеры с процессором DEC Alpha, я услышал такую фразу: «Хочу привезти компьютеры с UNIX, чтобы вы увидели настоящую графику». О достоинствах UNIX в качестве серверной платформы я на тот момент знал достаточно, а вот о том, что её сильная сторона – графика, услышал впервые. После терминалов IBM 360 и PDP-11, после DOS и Norton Commander, графическая оболочка Windows NT, запущенная на этих самым Alpha’х, казалась едва ли не верхом совершенства. Признаться, я усомнился в правоте своей знакомой, но, оказалось, напрасно.
В те далёкие времена АРМ’ы (автоматизированные рабочие места), сделанные на UNIX (будь то рабочее место раскройщика кожи или тренажёр космонавта), действительно выглядели более презентабельно, чем MS Windows, делавшая тогда лишь робкие первые шаги. Шли годы, персональные компьютеры теснили мини-ЭВМ и мэйнфреймы, как млекопитающие динозавров, а вслед за ними и MS Windows становилась всё популярнее, тогда как о UNIX применительно к IBM PC сказать было нечего: его просто не было. Положение изменилось с появлением Linux. Идеи и наработки, накопленные за годы существования UNIX, стали постепенно находить себе место и на персональных компьютерах.
Оставим в стороне принципиальные различия между миром Open Source и проприетарным ПО. Сосредоточимся на графической оболочке *nix-ов. Как известно, все они используют открытую реализацию 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) достаточно точно отражает и характер, и уровень требований.
Прежде всего, это значит, что речь идёт о TrueType-шрифтах. Вывод растровых шрифтов давно уже не является проблемой, а использование свободных масштабируемых шрифтов, традиционно входящих в состав X Window, как бы совершенна ни была их прорисовка, оставляет пользователю, привычному к виду Windows, основания быть недовольным. Сила ли привычки определяет его отношение, или шрифты из состава X Window действительно так уступают Arial/Tahoma/Verdana/Trebuchet – не суть важно. Не будем также касаться правомерности использования TTF-шрифтов из состава Microsoft Windows. Зададимся иным вопросом: можно ли в X Window видеть их такими же, как в XP? Если «в принципе – да» , то почему буковки меньше и вообще как-то «аляповато»? Смотрим на рис. 1.
Первым и самым главным (в случае его наличия) недостатком является компиляция библиотеки 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 (в /usr/include) и конфигурационный файл freetype2.pc. «Можно», а не «нужно», поскольку если вы «простой пользователь», то include и freetype2.pc вам, скорее всего не понадобятся. Если же «прелести самосборки» вам не безразличны, то вы и сами все знаете – включая то, что после установки новых библиотек рекомендуется запускать ldconfig.
DPI
Когда с libfreetype будет всё в порядке, а рабочий стол перестанет вызывать приступы острой жалости, можно перейти к следующему шагу и попытаться ответить на вопрос: почему один и тот же шрифт одного и того же кегля выглядит имеющим разный размер под XP и X Window? См. рис. 2.
Дело в том, что ключевым параметром при создании векторных изображений является так называемый DPI – «dot-per-inch», который говорит о том, сколько точек (пикселей) помещается на экране в отрезке длиной дюйм. Казалось бы: разрешение известно, физический размер экрана - тоже, какие трудности? Тем более, что все современные мониторы имеют так называемый DDC (Display Data Channel) и по запросу выдают блок информации, в котором, среди прочего, должны присутствовать данные о физических размерах экрана. К сожалению, не-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 шести и даже 12-ти. Так или иначе, но произвольные значения dpi, которые MS Windows позволяет устанавливать, воспользовавшись масштабом «Custom», достаточно часто приводят к заметному ухудшению отображения. Отметим пока эти три числа и вернёмся к X Window.
Воспользовавшись вышеупомянутой утилитой, можно узнать, каким X Window полагает размер экрана:
xdpyinfo | grep dimension
Выведенное в ответ разрешение экрана не удивляет (сами ведь задавали), размер экрана в миллиметрах получен, очевидно, от монитора, но вот насколько расчитанный dpi соответствует оптимальному рендерингу?
Поскольку в документации X Window рекомендаций по этому поводу найти не удалось (да и какой линуксоид не предпочтёт собственные эксперименты чтению документации?), впору перейти к описанию способов задания dpi. Итак:
- Начнём с /etc/X11/xorg.conf. В секции “Monitor” строкой
DisplaySize www hhh
можно задать те самые размеры экрана в миллиметрах, которые xdpyinfo выдаст потом как dimension. Соответствующий dpi будет получен в результате простейших арифметических действий;
- Если X Window запускается из консольного режима, dpi можно задать в явном виде:
startx -- -dpi NN
или отредактировать сам скрипт /usr/X11R6/bin/startx, позаботившись о наличии строки:
defaultserverargs=”-dpi NN”
- Если система запускает X Window при загрузке, то регистрация пользователя (и, опционно, выбор оконного менеджера) выполняется каким-нибудь менеджером входа в систему, многие из которых могут задавать dpi для открываемой сессии. Для kdm в конфигурационном файле /opt/kde/share/config/kdm/kdmrc в секции [X-*-Core] можно ввести строку:
ServerArgsLocal=-dpi NN
При использовании gdm строка запуска X-сервера в файле /etc/X11/gdm/Xservers должна выглядеть так:
:0 local /usr/X11R6/bin/X -dpi NN
- Системы, применяющие fontconfig (то есть, к настоящему моменту, практически все), часто используют конфигурационный файл /etc/X11/Xresources. В этот файл достаточно включить строку:
Xft.dpi: NN
- В некоторых дистрибутивах, производных от Debian, в файле /etc/init.d/xsession нужна строка:
DPI=”-dpi NN”
Во всех перечисленных случаях NN – значение dpi. Что же касается того, каким должно быть это значение, то единого мнения нет. Никто не мешает поэкспериментировать, но если имеет место дефицит времени и желание воспользоваться «советами старых мастеров», то попробуйте dpi=75 или 100 для шрифтов из состава X Window, и наоборот – при «равнении» на MS Windows придерживайтесь ею же рекомендуемых значений (рис. 3).
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’...
К сожалению, не получится. Хотя все современные рабочие среды по умолчанию используют Xft, параметры рендеринга они задают самостоятельно. При этом в «Центре управления KDE» или «Настройках шрифтов Gnome» прямых аналогий параметрам fontconfig может и не быть, хотя в целом соответствие найти не трудно. Нас будут интересовать следующие параметры:
- antialias (сглаживание, отрисовка) – использовать или нет сглаживание глифов (элементов символов);
- hinting (уточнение, хинтинг) – использовать или нет уточнение;
- hintstyle (стиль уточнения): лёгкий, средний, полный;
- autohint – использовать или нет автохинтинг вместо обычного хинтинга. Можно бы и не упоминать: по умолчанию выключен во всех известных мне дистрибутивах;
- rgba – межточечное сглаживание (subpixel geometry): не использовать, rgb, bgr, vrgb, vbgr;
Возможности настройки fontconfig намного шире предлагаемых KDE/Gnome, поскольку позволяют задавать параметры для семейств шрифтов, отдельного шрифта, диапазона кеглей и даже определённого значения кегля. Типичный пример: отключение сглаживания для малых кеглей или, напротив, его включение для всех шрифтов семейства Vera. Вопрос только в том, захотите ли вы этим заниматься, тем более, если используете KDE, также позволяющий ограничивать сглаживание для диапазона кеглей. С другой стороны, к достоинствам Gnome следует безусловно отнести возможность «на ходу» менять dpi, моментально оценивая результат для конкретного шрифта и параметров сглаживания.
Насколько антиалиасинг улучшает вид текста, набранного сравнительно большим кеглем (текст страницы), и насколько, в то же время, он может быть неуместен (меню и панель навигации), демонстрирует очередной снимок экрана (рис. 4).
Из возможностей, предоставляемых исключительно 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 только одно), а о работе ЭЛТ нельзя судить без указания частоты кадровой развёртки (refresh rate).
Механизмы рендеринга MS Windows и X Window не идентичны. С учётом варьирования dpi и зависимости от этого отображения различных фонтов, нет смысла гнаться за полной идентичностью рабочих столов. Некоторые TrueType-шрифты при особо малых кеглях могут вообще демонстрировать дефекты начертания, отсутствующие в MS Windows. Это, однако, исключение. В большинстве случаев при «прочих равных условиях»: dpi, сглаживание (в MS Windows это называется “method to smooth 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 испытывают друг к другу если не неприязнь, то жалость, и при этом существует ряд приложений, применяемых и теми, и другими. Прежде всего, это OpenOffice.org, Gimp, Mozilla «с потомками», ROX Filer и т.д.
Как может выглядеть приложение, использующее не тщательно подобранные вами в «Центре управления KDE» шрифты и кегли, а что-то совершенно чуждое? В большинстве случаев – плохо. Чтобы этого не было, укажите те же шрифт и кегль gtkrc-2.0, что используете в качестве «обычного» или «меню» . Например:
gtk-font-name = “Tahoma 8”
Элементы управления схожими не станут [для этого можно использовать специальные темы, например, Gtk/Qt Engine или QtCurve, – прим. ред.], но ROX с Firefox’ом в рамках KDE глаз станут резать гораздо меньше. Пользователи Gnome аналогичным образом могли бы поступить с qtrc, но Qt-приложений, незаменимых в среде Gnome, я практически не знаю. См. рис. 5.
Раз уж мы уделили столько внимания конфигурационным файлам, то укажем ещё два: ~/.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 можно прочитать в www.mozilla.org/unix/customizing.html. Подобным образом userContent.css задаёт параметры вывода просматриваемых страниц. Однако, поскольку параметры вывода текста этих страниц можно менять и через «Настройки», мало кто этим пользуется.
И снова: не обольщайтесь. Авторы тем тоже знают, что такое каскадные таблицы стилей, и однажды поменяв тему, вы можете обнаружить, что шрифты опять «съехали». Обсуждение использования CSS-файлов в Mozilla, опять-таки, не тема настоящей статьи.
Итоги
Так могут ли шрифты под X Window выглядеть лучше, чем под XP? Наверное, иногда действительно могут, поскольку возможностей для «тонкой» настройки рендеринга X Window предоставляет явно больше. Разнообразие возможностей, однако, хотя и является источником прогресса, всегда способствует поддержанию некоторого уровня беспорядка (и это ещё мягко сказано). Приятное же глазу единообразие создать можете либо вы сами, либо автор вашего дистрибутива. Причём во втором случае, «дистростроитель» должен обеспечить унификацию настроек предлагаемых им приложений, а вам рекомендуется использовать пакеты исключительно своего дистрибутива.
Настойчивый и компетентный пользователь всегда может добиться желаемого результата. С другой стороны, Linux-хиты последнего времени, такие, как Ubuntu/Kubuntu, выглядят в сравнении с XP вполне достойно. Будем надеяться, что и впредь программисты X.Org будут развивать систему, используемую в качестве основы для различных моделей рабочих столов. Разработчики графических сред смогут предложить исчерпывающе полные реализации «пользовательских окружений». А составители дистрибутивов постараются избавить «простых» пользователей от многочисленных настроек – с одной стороны, и разочарований при сравнении с Windows XP – с другой.
