24 января 2011 в 04:37

Разоблачение алгоритмов растеризации шрифтов (2/2) перевод

(вторая часть перевода статьи Разоблачение алгоритмов растеризации шрифтов)

Linux


Наследуя худшее


Windows растеризует шрифты плохо, Linux ещё хуже. Во всех Linux-системах, которые я видел, используется FreeType [10] Дэвида Тёрнера, Роберта Вильгельма и Вернера Лемберга. Это отличная библиотека, но способ её использования, к сожалению, нельзя назвать удачным. Типичный скриншот Linux выглядит так:



Вот полный скриншот:
ссылка

Сразу заметна проблема — чёрные пятна в скругленных углах, образовавшиеся в результате сглаживания. Вцелом, можно сказать, что косые штрихи выглядят тяжелее чем вертикальные, что в регультате производит впечатление «грязи». Вы можете возразить, что FreeType и Linux могли бы использовать схожую с ClearType субпиксельную растеризацию, но по мне это не даёт заметных преимуществ.



Посмотрите на «W», «v» и «y» — проблема в сущности та же, символы выглядят грязно. Можно слегка улучшить ситуацию в углах, используя корекцию гаммы в процессе растеризации, но это всё равно не позволит добиться идеального отображения.

Коррекция гаммы


Коррекция гаммы работает так:



Как вы могли заметить, скругленные углы со сглаживанием смотрятся значительно лучше с гаммой 2.0. Коррекция гаммы — отдельная нетривиальная тема, и, если вам интересно, вы можете найти исчерпывающую информацию в «Gamma FAQ» Чарльза Пойнтона [6].

В нашем случае речь не идет о кривых «исходный сигнал — результат» в электронных цепях, скорее, о специфике человеческого зрения. Зрительная реакция примерно пропорциональна квадратному корню физической светимости. Другими словами, если у нас есть два белых пикселя на черном фоне, и один из них излучает в два раза больше фотонов, чем второй, это не значит, что он будет выглядеть в два раза ярче. На самом деле, где-то в 1,4 раза. Вы можете легко убедиться в этом:



Справа — два пикселя, и мы можем с уверенностью сказать, что они излучают в два раза больше фотонов в секунду, чем пиксель слева. Тем не менее, они не выглядят в два раза ярче. Четыре пикселя дадут примерно в два раза большую яркость, но никак не два.

Опустив лишние объяснения, мы можем сказать, что есть два основных цветовых пространства RGB: субъективно равномерное, которое называется sRGB, и физически равномерное. В последнем значение пропорционально физической светимости, в отличие от sRGB, в котором значение пропорционально субъективной светимости. Обычно физически равномерное цветовое пространство называют просто «линейный RGB». При использовании сглаживания сведение цветов должно производиться в линейном пространстве, но перед выводом на экран необходимо привести цвета к sRGB. На практике этот шаг часто игнорируется, и сглаживание выполняется непосредственно в sRGB. Во многих случаях это дает приемлимый результат, но не для растеризации текста, что можно продемонстрировать прямо в Microsoft Word. Штука в том, что они используют некий трюк для выделения текста, что-то типа тривиальной инверсии, вместо перерисовки с нуля. С обычным, черно-белым сглаживанием выделенный текст смотрится грязно. С ClearType он приобретает цветную кайму:



Так что мы можем сделать вывод, что в Windows выполняется корректная коррекция гаммы (но не для выделенного текста), в Linux же её обычно игнорируют. FreeType может легко применить нужное преобразование гаммы к черно-белой маске сглаживания, которую генерирует растеризатор. Но это будет работать так же, как в Windows: инверсия цветов даст инверсию гаммы. На практике это безполезно, так как гамма должна применяться по отдельности к каждому цветовому компоненту до смешивания (что на практике эквивалентно работе в линейном RGB). Поэтому коррекция гаммы для черно-белой маски поможет, только если вы выводите черный текст на белом фоне. В этом случае вы можете использовать для коррекции значение в районе 2. Но если вы выводите белый текст на черном фоне, вам нужно инвертировать значение гаммы, то есть, использовать что-то около 0,5. Проблема в том, что вы не знаете точного цвета текста и фона, текст также может быть выведен поверх градиента или изображения. Так что «черно-белая» коррекция гаммы не сработает, а «полноцветная» коррекция гаммы может быть дорогостоящей и сложной в реализации. Проблема в том, что для линейного RGB нужно больше 8 битов на канал, иначе вы неизбежно получите потери цвета. Для текста это может быть допустимым, но вы не можете требовать этого для всего рабочего стола! А работа в линейном RGB, используя по 16 бит на канал — до сих пор непозволительная роскошь.

Гамма не работает


На самом деле, ситуация ещё хуже. Вы можете применить коррекцию гаммы со значением, равным 2 к скриншоту с Linux в том же Irfanview (Image->Enhance colors...) и посмотреть на текст. Пожалуйста, постарайтесь не обращать внимание на то, что пиктограммы выглядят пересвеченно, сконцентрируйтесь на тексте.



Вам нравится? Мне всё ещё нет. Когда я работал над растеризацией текста в AGG, я думал, что правильная коррекция гаммы может решить все проблемы. Ничего подобного! Независимо от того, насколько хорошо она работает, некоторые элементы выглядят толще, а некоторые — тоньше, чем вертикальные и горизонтальные штрихи. Это сильно заметно на шрифтах без засечек, и особенно — когда штрихи жёстко выровнены по пикселям. Проблема в том, что хинтинг TrueType был специально разработан для обычного черно-белого растеризатора без сглаживания! Использование любого сглаживания формально некорректно, а большинство Linux систем делают именно это. Изображение ниже — результат растеризации со сглаживанием с применением как FreeType, так и GetGlyphOutline().



Текст выглядит паршиво и это очень похоже на то, что мы в большинстве случаев наблюдаем в Linux. Здесь не поможет никакая коррекция гаммы. Для примера, лучший результат у меня получился со значением гаммы равным 1,5. Всё ещё выглядит плохо:



По ходу дела вы должны были заметить, что, начиная с определенного размера текст начинает казаться тяжелым. Это именно то, что происходит в Windows. Если вы выключите ClearType, это будет очевидно (размер текста не сохраняется в точности).



В общем, идею вы поняли. Чтобы она стала более очевидной, мы можем увеличить векторное изображение, которое возвращает функция GetGlyphOutline() из Win32 API, и посмотерть, что будет происходить.



Вот так работает патентованный агрессивный хинтинг для номинального размера в 13 пикселей. Вот почему штрихи в «k» выглядят такими тонкими, почти невидимыми. В курсиве Times New Roman всё ещё хуже: полностью исчезает косой штрих в «z». Искажения не влияют на обычный растеризатор без сглаживания, но тот, что использует FreeType, чувствителен к этим вещам. Он непосредственно рассчитывает степень покрытия пикселей, так что он честно получает нулевое покрытие для косого штриха «z». То есть выясняется, что нет никакого смысла интерпретировать байткод TrueType для хинтинга (не говоря уже о том, что вам придется покупать лицензию). Сглаживание это хорошо, но его не стоит применять ради самого себя. В любом случае, я бы предпочел текст без сглаживания, если оно используется в паре с неадекватным хинтингом.

Автохинтер FreeType


В FreeType версии 2 Дэвид Тёрнер представил механизм автохинтинга. Он работает вполне неплохо, но, тем не менее, непосредственное его применение даёт результат, далёкий от идеального. Посмотрите на результат растеризации гарнитуры Verdana с гаммой 1,5:



Сравните с примером без хинтинга:



Версия без хинтинга определенно выглядит более аккуратной, но и более размытой. Есть три основные различия:

  1. Автохинтинг всё ещё даёт ошибки в скругленных элементах небольшого размера (та же визуальная разница в толщине между вертикальными и косыми штрихами).
  2. Иногда автохинтинг приводит к некорректному кернингу, как в «og» в слове «Dog» (в этом примере использовалась кернинговая таблица из шрифта).
  3. Автохинтинг приводит к той же проблеме накопления ошибки на протяжении строки текста, в результате чего правый край текста приобретает «зазубрины».

Автохинтер работает лучше с более сложными шрифтами, такими как Times New Roman, но всё равно встречаются те же проблемы позиционирования.

Что же делать?


Заглядывая вперед, я покажу вам ещё один пример.



Всё-таки возможно найти приемлимое решение! Но для начала вам нужно согласиться, что нет способа использовать хинтинг любого рода и при этом сохранять корректное расположение текста на любом масштабе. Только текст без хинтинга, с его естественной размытостью. Тем не менее, мы можем улучшить растеризацию, хотя нам и придется пожертвовать чем-то не очень важным. А именно, мы можем позволить себе небольшую неточность в вертикальном позиционировании и высоте текста. Кроме всего прочего, хинтинг TrueType работает так же: строки текста высотой, скажем, 12 и 13 пикселей будут на экране иметь одну и ту же высоту, хотя выглядеть будут по-разному.



Короче говоря, для приятного глазу текста и при этом сохранения аккуратного горизонтального позиционирования нам нужно следующее:

  1. Использовать горизонтальное субпиксельное RGB-сглаживание на мониторах LCD.
  2. Использовать только вертикальный хинтинг и полностью отказаться от горизонтального.
  3. Использовать точные значения смещения глифов, вычисленные на высоком разрешении для глифов без хинтинга.
  4. Использовать точные значения высокого разрешения из таблицы кернинга.

Небольшая коррекция гаммы может улучшить результат, но это не обязательно. Текст смотрится хорошо даже непосредственно в sRGB, а это значит, что не будет проблем в инвертированных цветовых схемах.

Вы можете легко добиться приемлимого результата с FreeType и её автохинтером. Это значит, что вам не нужно беспокоиться о лицензировании патентованного хинтинга TrueType. То же самое можно проделать, используя функцию GetGlyphOutline() из Win32 API. Это сложнее, но всё равно возможно.

Субпиксельная растеризация в RGB


Вы можете найти исчерпывающее руководство по использованию субпиксельной растеризации в RGB на страницах Стива Гибсона, «Технология субпиксельной растеризации» [2]. Я также пробовал использовать эту технологию с 64-уровневыми растровыми изображениями со сглаживанием, которые может генерировать GetGlyphOutline(): Максим Шиманарев, «Как устроен ClearType в Windows Longhorn» [3] (UPD: ссылка протухла, но можно прочитать здесь, здесь или здесь). Вы можете скачать демонстрационную программу для Windows со всеми исходниками по этой ссылке:
antigrain.com/stuff/lcd_font.zip

Кроме того, я написал простой, «на коленке за вечер», растеризатор для AGG. Его можно найти в демонстрационных примерах, которые последуют ниже. На данный момент код небезопасный и довольно медленный. Это нормально для демонстрационных программ, но неприемлимо в реальном проекте, в первую очередь из-за того, что он использует временный буфер для не более 2048 пикселов в стеке.

В самом простом случае, всё что нам нужно, это значения прозрачности для каждого цветового канала. В данном файле, agg_pixfmt_rgb24_lcd.h. Я также использовал дополнительное размытие, которое описывает Стив Гибсон. Оно выполняется на ходу, хотя может быть выполнено заранее с использованием некого механизма кэширования. В этом случае оно будет работать значительно быстрее, как минимум, не медленнее, чем классическое альфа-смешивание.

Для отладки смешивания по каналам я использовал программу ZoomIn [9] Брайана Фрайзена. Я добавил «декодирование» троек цветов на всех масштабах, кратных трём. Вы можете скачать исполняемый файл здесь: antigrain.com/stuff/ZoomInLcd.zip (в 2005м я потерял модифицированные исходники. В любом случае, эти модификации нетрудно выполнить самостоятельно). Вы можете сравнить увеличенные результаты обычной черно-белой и субпиксельной RGB растеризации:


Черно-белая растеризация


Субпиксельная RGB растеризация

Другие нюансы


Чтобы сохранить вертикальный хинтинг, но избавиться от горизонтального, мы просто обманем хинтер: растянем символы по горизонтали так, чтобы хинтер был вынужден работать с высокой точностью. Проблема в том, что шрифтовой движок AGG для FreeType использует неточные значения смещения, учитывая хинтинг. Технически, хинтер должен вычислять точные значения смещения для сильно растянутых глифов, но по непонятной причине он этого не делает. Мне пришлось модифицировать его, чтобы использовать исходные, «нехинтованные» смещения. Измененная версия также включена в демонстрационные программы. После того как кривая глифа получена, мы используем аффинное преобразование, чтобы сжать её обратно. В самом простом случае это всё что нам нужно. Таблица кернинга содержит достаточно точные значения.

Так что я хочу обратиться к Дэвиду Тёрнеру: может быть, есть смысл добавить в его автохинтер опцию, которая позволяла бы выполнять хинтинг только по оси Y, игнорируя хинтинг по оси X? Или можно сделать отдельный 1-D хинтер, значительно проще существующего. Как вы увидите, текст с субпиксельной RGB растеризацией смотрится очень похоже на Adobe Acrobat Reader, и, в любом случае, гораздо лучше, чем в любой современной Linux системе (статья написана в 2007 году — прим. перев.). Я верю, что это поможет продвижению и увеличению популярности систем на основе Linux.

Использование Windows API существенно сложнее. Функция GetGlyphOutline() возвращает значение смещения в целочисленных пикселях, что для нас слишком грубо. Растягивание не спасает. Есть ещё функции вроде GetCharABCWidthsFloat(), но они бесполезны, так как они рассчитывают значения для хинтованных глифов и несмотря на тот факт, что они содержат числа с плавающей точкой, всё равно, на самом деле, это целые числа. Так что я не нашел простого способа получить точные смещения. В результате мне пришлось использовать два шрифта одновременно, один высотой в 1024 пикселя, а другой нужного нам размера, с хинтингом и растянутой аффинной матрицей. Я допускаю, что мог что-то пропустить, но у меня нет мыслей о том, как это можно реализовать более корректно. Возможно, в Microsoft Word они используют какие-то недокументированные функции, что является абсолютно нечестным с точки зрения конкуренции. Конечно, я не могу быть в этом полностью уверен, но ситуация заставляет меня думать, что Microsoft намеренно не предоставляет достаточного хорошего API для разработки средств работы с документами WYSIWYG. Это типичная политика монополиста, которая в результате приводит к торможению технического прогресса.

На самом деле, всё ещё хуже. Патентованный хинтер не работает с «растянутой» матрицей! Как минимум, я не нашел ни один коэффициент масштабирования, который бы корректно обрабатывал глифы. Работал корректно только масштаб 1:1, но в результате я получил те же проблемы, которые вынудили меня использовать чёрно-белый растеризатор без сглаживания:



Выглядит жутко, не правда ли? Любое масштабирование приводило к сильно испорченным глифам. Вот, например, курсив Times New Roman (16-кратное растягивание по горизонтали):



Или даже так. Arial (100-кратное растягивание по горизонтали) — забавные подтёки, да? Но читать невозможно:



Думаю, нет смысла говорить, что автохинтер FreeType работает корректно при любом растягивании.

Выглядит так, будто бы Microsoft API — просто набор нездоровых случайных решений «на коленке» без всякой инженерной культуры и глобальной идеи, стоящей за всем этим. Как правило, вы можете использовать ПО Microsoft только одним жёстко предопределенным образом. Шаг вправо, шаг влево — и всё пропало. Быть может, это и хорошо для их бизнеса, но, как минимум, нечестно. Такая политика нарушает условия равноправной конкуренции и в результате замедляет общий прогресс на рынке. Антимонопольному комитету следовало бы обратить внимание на эту ситуацию, вместо смешных требований убрать из системы Media Player или Internet Explorer.

В конечном итоге я выяснил, что значение «16» — меньшее зло, оно подходит для большинства случаев, но всё ещё не срабатывает для курсива Times New Roman.

Демонстрационная программа


Вот она, программа для Windows, использующая TrueType:
www.antigrain.com/research/font_rasterization/truetype_test_02_ft.zip

А вот версия, которая использует Windows API:
www.antigrain.com/research/font_rasterization/truetype_test_02_win.zip

Версия под FreeType требует наличия в каталоге программы следующих файлов: arial.ttf, ariali.ttf, georgia.ttf, georgiai.ttf, tahoma.ttf, times.ttf, timesi.ttf, verdana.ttf, verdanai.ttf. Вы можете найти их в папке %WINDIR%\Fonts.

Если вы захотите скомпилировать её, скачайте AGG версии 2.4 или 2.5 и распакуйте файлы куда-нибудь вроде agg-2.4\research\win32\trutype_lcd\*.*. Для версии под FreeType вам также понадобится самостоятельно собрать FreeType, и, возможно, изменить настройки проекта.

Программа также может быть собрана для Linux/X11 или другой системы, если вы напишите соответствующий makefile, подобный тем, которые используются в примерах AGG.

Текст в версиях под FreeType и под WinAPI выглядит по-разному из-за разных алгоритмов хинтинга.



Вы видите здесь большое количество настроек. Во-первых, мы можете менять шрифты, а также включать или выключать кернинг, хинтинг и субпиксельную RGB растеризацию. Кроме того, вы можете инвертировать изображение, чтобы получить белый текст на черном фоне.

Слайдер «Font Scale» позволяет плавно менять размер шрифта. Как вы можете заметить, при включенном хинтинге линии привязаны к пикселям, но при этом ширина текста продолжает изменяться плавно. Вы сможете лучше разглядеть этот эффект, изменяя интервал. Без хинтинга разположение текста идеально сохраняется на любом масштабе, но текст выглядит размытым. Вертикальная привязка линий — наиболее разумный компромисс между резкостью и точностью расположения текста. Я сам в шоке от того, насколько вертикальный хинтинг улучшает качество и при этом сохраняет форму символов.

Слайдеры интервала, ширины и «имитации курсива», я думаю, не нуждаются в комментариях. Для людей, знакомых с компьютерной графикой, очевидно, что это обычные аффинные преобразования. Я бы хотел отметить только один факт: в режимах «черно-белый» и «субпиксельная RGB растеризация» слайдер «имитация курсива» работает немного по-разному. Это происходит потому, что я был слишком ленив, чтобы обрабатывать его значения корректно, через арктангенсы. В любом случае, это несущественно.

Функция, которой я особенно горжусь, это «имитация полужирного». Она работает так:



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



Размытия избежать легко. Мы растягиваем глифы по вертикали, скажем, в 100 или 1000 раз, вычисляем эквидистантный многоугольник и сжимаем его обратно. Так что в результате координаты по оси Y почти не меняются и текст остаётся чётким. В демонстрационной программе есть класс «faux_weight». Опять же, потрясающе, сколько возможностей даёт свободное горизонтальное масштабирование. И не менее потрясающе, насколько привязка к пикселям по вертикали улучшает визуальный результат.

Ещё один пример (я люблю эту свободу):



Это всё та же гарнитура Georgia, но только программно преобразованная. Вполне читаемая, чёткая и гладкая одновременно (да, я согласен, ей бы не помешал ручной кернинг).

Или тоже самое для гарнитуры Tahoma:



Слайдер регулировки гаммы управляет корекцией гаммы (она выполняется отдельно для каждого канала). Теоретически, следует применять «непосредственную гамму» к исходным цветам, а затем, после отрисовки сцены, применять «инвертированную гамму». Но, поскольку текст в этих примерах всегда белый или черный, в первой операции нет никакого смысла.

Слайдер «первичный вес» управляет распределением энергии также, как это описано у Стива Гибсона: www.grc.com/freeandclear.htm. Достаточно хорошо управлять только первичным весом, а остальные рассчитывать соответственно. Увеличивая первичный вес вы можете сделать текст чётче, но при этом появляется цветной контур вокруг знаков. Имеет смысл использовать значения до 0,5, при больших значениях цветовое «свечение» становится слишком заметным. Как по мне, Windows ClearType тоже даёт слишком заметное цветное «свечение».

Такая растеризация может работать быстро


Демонстрационная программа довольно медленная. Отчасти потому что векторные операции производятся на лету, но в первую очередь из-за функции WinAPI GetGlyphOutline(), которая сама по себе ужасно медленная. С другой стороны, подобная растеризация может быть не менее быстрой, чем любая аппаратно ускоренная растеризация текста. Но для начала вы должны согласиться с тем, что акселерация растеризации произвольно изменяемого текста с сохранением хинтинга, корректной разметки и чёткого субпиксельного качества — в принципе непростая задача. Под произвольными трансформациями я имею в виду действительно произвольные, включая перспективу и любые нелинейные преобразования.

Большую же часть времени нам приходится иметь дело с горизонтальным текстом, даже при использовании восточно-азиатских языков. К тому же, большую часть времени глифы используют один и тот же номинальный размер. Из этого следует, что здесь пригодился бы механизм кэширования. Субпиксельная черно-белая маска для трёх каналов RGB требует в три раза больше памяти, но в то же время дает точность позиционирования текста до 1/3 пикселя. В большинстве случаев это работает достаточно хорошо. Разве что для теоретической «роскошной» растеризации вы можете использовать две черно-белые маски на глиф, получая точность в 1/6 пикселя. Даже программное альфа-смешивание работает достаточно быстро — порядка 2-4 мс на глиф на современных процессорах Intel или PPC. С использованием GPU это может происходить ещё быстрее, если загрузить соответствующие текстуры. Единственная проблема — GPU должен позволять альфа-смешивание по каналам, что, насколько я знаю, представляется возможным. Как минимум, Дэвид Браун упоминает об этом в своей презентации [8]. Но я не смог найти больше информации по этой теме (как получить 6-канальный вывод из пиксельного шейдера) и я был бы благодарен, если бы вы предложили мне какие-нибудь ссылки по этой теме.

Ссылки


  1. Joel Spolsky, Font smoothing, anti-aliasing, and sub-pixel rendering.
    www.joelonsoftware.com/items/2007/06/12.html
  2. Steve Gibson, Sub-Pixel Font Rendering Technology.
    www.grc.com/cleartype.htm
  3. Maxim Shemanarev, Inside ClearType in Windows Longhorn.
    www.byte.com/documents/s=9553/byt1113241694002/0411_shemanarev.html
    (requires online registration.)
  4. FontFocus white paper, artofcode.com/fontfocus
  5. Jeff Atwood, Font Rendering: Respecting the Pixel Grid.
    www.codinghorror.com/blog/archives/000885.html
  6. Charles Poynton, Frequently-Asked Questions about Gamma.
    www.poynton.com/GammaFAQ.html
  7. Dave Shea, A Subpixel Safari.
    mezzoblue.com/archives/2007/06/12/a_subpixel_s
  8. David Brown, Avalon Text. A PowerPoint presentation.
    download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04007_WINHEC2004.ppt
  9. Brian Friesen, ZoomIn Program.
    www.csc.calpoly.edu/~bfriesen/software/zoomin.shtml
  10. David Turner and the others, FreeType font Library.
    freetype.org
  11. Jim Mathies, XP Style DPI Scaling.
    www.mathies.com/weblog/?p=908
  12. Long Zheng, Windows Vista DPI scaling: my Vista is bigger than your Vista
    www.istartedsomething.com/20061211/vista-dpi-scaling

PS: Первая часть статьи в вебархиве (с картинками). Вторая часть статьи в вебархиве (с картинками).

PPS: Несколько любопытных ссылок для интересующихся темой экранной типографики:
Кегль шрифта: не всё так просто
Шрифты на бюджетном мониторе в Windows 8
Высокие значения DPI в ОС Windows
В защиту программистов
Перевод: Maxim Shemanarev
Иван Сорокин @unxed
карма
112,1
рейтинг 0,0
Пользователь
Похожие публикации
Самое читаемое Дизайн

Комментарии (48)

  • +5
    Всегда хотел разобраться в типографике (а также причине, почему текст на экране выглядит именно так, как выглядит)) и всегда попадались какие-то обрывочные статьи. Эта же — просто супер, низкий поклон переводчику и автору.
    • +2
      Я выступлю в некоей роли в виде «адвоката дьявола», но все-таки рискну сказать, что при всей объемности исследования и при том, что оригинальный автор написал свой собственный растеризатор, основную мысль автора можно сформулировать в одну строчку:

      «Единственно верный способ растеризации шрифтов — с антиалиасингом, с субпиксельным сглаживанием, с хинтингом по Y и отсутствием хинтинга по X».

      Как и почти все «вкусовые» решения — к сожалению, это просто одно из мнений. Для тех, кто последует этому мнению — ничего автоматически не произойдет, не начнут сваливаться с неба мешки денег, довольные заказчики и т.п. Кому-то это будет нравится, кому-то — нет.
      • +7
        Для меня суть статьи не в том, что автор показал _что_ ему нравится, а том, что он рассказал _как_ и _почему_ это работает. (Прошу прощения за 3 «что»))
        P.S. Но согласитесь, при его подходе шрифты выглядят и ведут себя лучше, чем в «дефолтных» вариантах. Разве нет?
        • +7
          Мне лично вообще хинтинг кажется зверством и диким пережитком 90-х, когда разрешение у мониторов было правда порядка 640*480 на 15" => 53 PPI, ну или в лучшем случае 1024*768 на 17" => 75 PPI.

          Современные мониторы и ноутбуки вполне уже технологически готовы к тому, чтобы поставить нижнюю планку где-то в районе 110-120 PPI, а для мобильных устройств мы подходим вплотную к 220-300 PPI (т.е. многократно лучше, чем средненький лазерный принтер).

          Если отказаться от зверского искажения форм глифов шрифтов в угоду тому, чтобы их края попадали в целые пиксели (и начать жить, наконец-таки, с толщиной штриха не в 1-2 пикселя, а хотя бы в 3-4-5), то шрифты вдруг начинают выглядеть интересно, у них появляется некий характер, начинаешь отличать разные sans'ы и sans serif'ы друг от дружки, начинаешь замечать определенные графические решения и т.д. и т.п.

          Если же мы все-таки хотим говорить о низких разрешениях (и PPI), то здесь я никогда не понимал смысла использования векторных шрифтов вообще. Какая-нибудь вручную растрированная Lucida или Terminus дадут сто очков вперед любой растеризации векторного шрифта на таких разрешениях.
          • 0
            А там же нет никакой толщины штриха. Оно же всё рендерится многоугольниками, а не линиями. И ещё вопрос: а зачем стремится к интересности шрифта? Я понимаю, например, когда речь идёт о вывеске для магазина или там рекламном плакате, это имеет значение. Но когда мне надо читать учебник по квантовой механике или писать программу, то чем проще шрифт, тем лучше, чтобы не было дополнительного насилия над мозгом в виде необходимости распознавать и отфильтровывать все эти интересности.

            Поэтому, бррРр. Шрифт для работы с текстом должен быть абсолютно прямой, тупой, без всяких завитушек. Чёткий, не размазанный, не подкрашенный на границах всеми цветами радуги при subpixel-rendering (ну различаю я эти subpixels, очень хорошо различаю, и это мешает).

            Почему-то потребности людей, которые профессионально работают с текстом (с содержимым, а не с тем, как оно выглядит) никак не учитываются. И это печально.
            • +1
              Это всё вкусовщина конечно, но бумажные книги издавна печатались антиквой, и я никак не могу сказать, что новомодный набор рубленым шрифтом с изрезанным правым краем и без абзацных отступов хоть в чём-то лучше для восприятия, хотя он именно что «прямой и тупой».
              В экранных шрифтах точно не будет единогласия до повсеместного распространения 300 ppi дисплеев. Вас раздражают радужные ореолы, верю. Я их почти никогда не вижу (в линуксе по крайней мере, ClearType пестрит гораздо больше), у меня действительно плохое зрение (хотя при 100 ppi пиксель на расстояние 60 см — это меньше 2′, что близко к пределу разрешающей способности здорового глаза). Но меня при этом напрягают лесенки растровых шрифтов, их я почему-то вижу и создаваемый ими шум не переношу.
              • 0
                Так разве абзацные отступы и переносы — это проблема шрифтов? Я могу и Верданой набирать всё в TeX аккуратно.

                НО. У меня есть два сомнения на счёт того, что Вы написали.

                1. Я сомневаюсь, что у нас будут 300dpi дисплеи. Его, конечно, можно изготовить, но какого он будет размера? Если обеспечивать и размер, и такой мелкий пиксель, то какого же разрешения такое устройство должно быть? А это уже чисто технологическая проблема: как развести столько проводочков?

                2. Как бы нам не было печально (я среди скорбящих по закрывающимся книжным магазинам), но бумага будет уходить из оборота. Останется, скорее всего, как вариант для элитных, очень дорогих изданий, и как архивная hardcopy, которая требует минимум технологий для прочтения. Но массовый пользователь будет читать и писать электронно. Да и уже так. Я давным давно не читаю бумажные книги, потому что, того, что мне интересно и нужно в книжном (даже Ozon) фиг найдёшь, приходится читать электронные варианты.

                То есть, как бы, область применения шрифтов поменялась, а нам по-прежнему пытаются обеспечить отрисовку текста на устройстве с заметными пикселями 'книжными' шрифтами. Вот взять тот же TeX, он же в итоге выдаёт некий документ для печати, а не для чтения на экране. И печатается всё просто отлично, но только проблема в том, что PDF'ки уже почти никто не печатает. Разве только для почеркаться, когда идёт какое-нибудь рецензирование.

                А необходимость читать вот эту PDF'ную размытую размытость, хоть ClerType'ом, хоть Graphite'ом, лично меня уж очень напрягает.

                Нужно, чтобы в головах компьютерных типографов уже что-то изменилось немного, и они начали придумывать другие алгоритмы, а то современные-то они же совсем примитивные. И все эти лесенки, когда идёт рендеринг без размазывания причины имеют две: (1) книжные шрифты, (2) ОЧЕНЬ примитивные алгоритмы растеризации. Весь этот subpixel rendering, который представляется, как продвинутая технология, на деле-то является просто расширением того же тупого отрисовывания трапециями фигурки буквы. IMHO, для того, чтобы сделать красиво, нужна немного другая геометрия и математика, но кто этим займётся? Если основная задача типографа-программиста — это вот ковыряние в настройке каких-то процентиков в баллансе яркости.

                БррРрр. Неприятная, imho, ситуация.
                • 0
                  1. Пример большого монитора с близким (200 ppi) разрешением — IBM T220. Пример маленького экрана с разрешением 300 ppi — iPhone 4. Вопрос в том, удастся ли снизить цену большого дисплея с таким разрешенеим до приемлемой. В этом я тоже сильно сомневаюсь.
                  2. А вот как избежать одновременно и размазывания, и лесенок, и шрифтов а-ля «семисегментный индикатор» я совершенно не представляю.
      • –2
        Всегда можно показать 1000 человекам три картинки и попросить выбрать ту, которая больше нравится. Это будет объективно.
        • +2
          Только нужно брать людей, не связанных с компьютерами, иначе они выберут не «лучшую» картинку, а похожую на то, к чему они привыкли
          • –1
            А как быть людям, которые связаны с компьютером? Зачем вообще делать рендеринг шрифтов для показа на мониторе компьютера, основываясь на мнении людей, которые с компьютерами не связаны? это какой-то non-sense получается.
            • +3
              Дело в том, что Вам сейчас дать новый шрифт (который объективно может быть лучше чем сейчас), то привычка заставит говорить, что он «какой-то не такой».
              А если производители ПО его насильственно ввели, то народ бы через какое-то время привык и всем бы стало лучше.

              Для меня, к примеру (хотя тут дело может быть в том, что я и от искусства далек, и зрение не очень) во многих случаях разница в шрифтах, или оформлении чего-либо малозаметна. Будь-то шрифты, обои, скринсейвер или цветовая гамма. Причём разницу-то я вижу, но оценить — как лучше не могу. Во многих случаях «лучшим» для меня кажется то, к чему я привык.

              Поэтому делать выбор нужно или на основе каких-то теоретических соображений, или предоставить выбор комитету людей, у которых не сформировалась привычка. В случае шрифтов — «не сформировалась привычка» у людей, которые не пользовались ранее компьютером.

              Хотя тут тоже есть подводные камни. Можно выбрать по принципу «больше нравится», а при длительной работе может оказаться, что утомление меньше от другого варианта, который изначально выглядел не так красиво.
              • 0
                Вообще-то, для этого есть профессиональные шрифтовики, которые специально изучают, от чего глаза больше устают, от чего меньше, почему один шрифт эстетичнее другого и т.д.

                Почему дизайн новых автомобилей делают и выбирают профессионалы, а в шрифтах мы должны доверяться случайной выборке некомпетентных людей?
                • +1
                  А, ну с этим согласен, если есть профессионалы, то не стоит на пользователей возлагать муки выбора.

                  Изначально-то я отвечал на комментарий про 1000 человек, и говорил, что если кто-то будет оценивать качество шрифта, то пусть это будут люди, со «свежим» взглядом, не приученные к какому-то определённому начертанию, за годы использования определённой ОС. Про профессионалов речи не шло.
                • –2
                  Ой. Вот это ещё хуже. Профессиональные шрифтовщики уже наворотили столько профессионального, что дико страшно. Простую буковку превратили в какой-то мегасложный объект, потому что реально, руководство по typesetting'у оно толще, чем учебник по Общей Теории Относительности раза в три, и во столько же раз непонятнее и запутанней. То есть реально, люди, которые занимаются типографией, совсем уже куда-то ушли в отрыв от потребностей простого читателя-писателя.
                  • +2
                    Напрасно вы так. Закопайтесь в любую узкоспециализированную область поглубже, и вы узнаете, что там тоже всё сопоставимо по сложности с ОТО ;-)
                    • 0
                      Так о том и речь: типографы копаются в каких-то там совершенно дремучих своих шрифтовых дебрях, а проблемы, заметные обычным пользователям, совсем не решаются: (
              • –1
                Ой, да ладно. Уверен, что большинство людей, связанных с компьютером просто плюются на шрифты существующие. Одна из популярнейших тем у программистов: народ, подскажите нормальный шрифт для работы. И этих шрифтов для программистов уже сотни вокруг, а всё никак нормальный не могут сгенерировать (вообще, не понимаю, в чём тут мистическая проблема: убрать засечки, расставить буквы пошире, сбалансировать ширину и высоту). Так что, у компьютерных людей нет никаких привычек, потому что не к чему привыкать, нет хорошего варианта.
                • 0
                  Ну у меня практически никогда не было недовольства стандартными шрифтами.

                  Может быть те программисты, что вечно ищут «идеальный» шрифт, ждут от него чудес?
                  Типа настроят IDE, и код будет писаться сам, можно будет работать по 20 часов и не уставать? Тогда понятно, почему до сих пор не нашли.
                  • 0
                    Вот здесь, в комментариях, много раз задается вопрос про идеальный шрифт «по умолчанию». Я думаю, там эта дискуссия будет уместнее, чем здесь. Я же, всё-таки, не профессиональный шрифтовик :)
                  • 0
                    Ну. Они ищут именно такой, от которого не уставали бы во время длительной работы. На который бы просто можно было бы не обращать внимния. Для меня вот такой шрифт для WEB-это Verdana. Минимум украшательств. Я не задумываюсь совсем о буквах, когда пишу этим шрифтом. А вот когда пишу Courier'ом, то часто скатываюсь в 'любование' буковками. Это плохо, в общем-то.
  • 0
    Части статьи в разных блогах.
    • +1
      Исправил, ага.
  • +2
    Интересно, но не для всех типов шрифтов отображение «как оно есть» подходит для компьютера, а сглаживание только мешает. Яркий пример — азиатские иероглифические шрифты (китайский, японский).

    Например, в Mac OS текст, написанный мелкими иероглифами, превращается в полную кашу и очень плохо воспринимается из-за попытки отобразить мелкий текст «как он есть». В этом плане, стандартный механизм отображения шрифтов Windows (и Ubuntu в стандартной поставке) намного лучше подходит для таких текстов. Пусть геометрия не на 100% соответствует тому, что нужно, но зато читаемость очень хорошая.

    Было бы здорово, если бы разработчики систем больше задумывались о том, что их могут использовать в других странах и с другими системами письменности. И, конечно, чем больше у пользователя «крутилок», тем лучше — можно настроить все под себя.
    • 0
      Вот, кстати, что меня всегда сильно поражало в шрифтах по умолчанию в операционных системах Microsoft — это то, насколько там красивые и читаемые растровые иероглифические шрифты. Вместить 4-радикальный иероглиф в сетку пикселей типа 8*8 — это надо иметь определенный талант :)
  • +2
    Кстати — Office:Mac 2011 использует FreeType
  • +2
    Почему бы просто не отключить сглаживание для шрифтов <10pt?
    • +2
      я у себя делал это както так…
      в файл /etc/fonts/fonts.conf и файл
      /etc/fonts/local.conf
      Добавляем:
      <match target="font">
          <test name="size" compare="less">
              <double>14</double>
          </test>
          <edit name="antialias" mode="assign">
              <bool>false</bool>
          </edit>
      

  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Хабр торт.
  • –2
    Одна из моих первых статей была именно про это. Для тех кого интересует современный код (без всяких там windows api), вот ссылка.
    • +1
      Пожалуйста, давайте не будем о том что «стильно, модно, молодежно» и что WinAPI это не модно. Простите, но темы вашей статьи и этого перевода, мягко говоря не одно и тоже. Да и если говорить о вашей статье, реализация, уж простите, не блещет.
      • –1
        Эмм… я к тому, что если вы посмотрите на исходники алгоритма в оригинале, то вряд ли много поймете, т.к. там помимо алгоритма еще а) использование winapi; и б) много бит-манипуляционной магии.

        А сам по себе алгоритм достаточно прост.
    • 0
      У вас в статье картинки пропали. Перезалейте, пожалуйста (на вебархиве их тоже нет, увы).
  • +1
    Где-то читал (возможно даже здесь, на хабре), что MS не использует в WinXP субпиксельное позиционирование для совместимости со старыми программами, чтобы текст в них сохранил ширину. То есть расстановка глифов в строке для TrueType шрифтов такая же, как и для шрифтов без сглаживания вообще.
    • +1
      Так и есть. При использовании gdipp ( code.google.com/p/gdipp/ ), который меняет рендеринг шрифтов с ClearType на FreeType, текст в некоторых формах не помещается в определенное для него место.
      • 0
        Это библиотека работает для шрифтов, отрендеренных средствами DirectX? Я, к сожалению, не имею представления как он работает.
        • 0
          Эта библиотека заменяет системный рендеринг шрифтов своим, основанным на FreeType. Она ставит хуки на функции вывода текста GDI.
          • 0
            en.wikipedia.org/wiki/ClearType#ClearType_in_WPF
            DirectX использует аппаратное ускорение для рендера текста, и встаёт вопрос — а использует ли он GDI вообще?
            Собственно вот, что я имел ввиду.
            • 0
              Нет, не использует.
      • 0
        Вау, спасибо за ссылку. Поставил.
    • +1
      в Vista, по умолчанию установлено 96dpi. у меня экран 129dpi и поэтому текст выглядит очень мелко. если выставить в настройках эти самые 129dpi, то текст во многих приложениях перестает помещаться в отведенную ему место.
  • 0
    Ни наю, ни наю. Но лично мне пример с автохинтингом больше понравился. Более чёткий и читабельный.
  • 0
    ID в URL второй части (112400) на единицу меньше ID первой части (112401). =)
    • 0
      Надеялся получить правильный порядок частей. Чтобы сначала на главной висела первая часть, затем — вторая.

      Не вышло.

      Зато в блоге «типографика» по порядку идут.
  • 0
    А есть какое-нибудь практичное пошаговое руководство, как сделать шрифты линуксе лучше?
  • 0
    Эх, очень жаль, antigrain.com видимо тоже ушел из жизни… и все рисунки к статье были туда…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.