Пользователь
0,0
рейтинг
24 января 2011 в 04:46

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

Попытка улучшить алгоритмы растеризации шрифтов, пользуясь исключительно общедоступной информацией.

От переводчика


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

Хочу отметить, что некоторые используемые термины не имеют общепринятых русских аналогов. Поэтому предупреждаю, что я буду переводить anti-aliasing как анти-алиасинг («сглаживание» — слишком общий термин), hinting как хинтинг (хинтование, на мой взгляд, не слишком благозвучное и совсем не распространенное слово), а rendering как растеризацию (в применении к шрифтам этот термин кажется мне более уместным, чем калька с английского).

Тем, кто ранее не интересовался темой типографики, есть смысл сходить по приведенным выше ссылкам, и разобраться, что значат все эти термины.

Статья опубликована в 2007 году, и самая старшая версия Windows, упоминающаяся в ней — Vista. Тем не менее, большая часть статьи актуальна и по сей день: в Windows 7 механизмы растеризации шрифтов недалеко ушли от Vista, а тенденция к переводу интерфейсов на веб платформу добавила к различиям растеризации в разных ОС ещё и различия растеризации в разных браузерах. Так что, на мой взгляд, приведенные в статье идеи не теряют акутальность до сих пор.

Хочу отметить, что попытка перевода статьи встретилась мне в RSDN wiki, но там дело не пошло дальше первых нескольких абзацев. Я не использовал этот перевод, но считаю уместным привести ссылку (UPD: ссылка протухла, но имеется тред на их форуме, где автор анонсирует саму статью).

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

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

Я традиционно стараюсь переводить единицы в метрические, кроме общепринятых в российской IT-индустрии, таких как DPI. Кроме того, я перевожу имена, но оставляю английские названия компаний и их продуктов.

Буду благодарен за любые дополнения или коррекции перевода. Об очевидных ошибках и опечатках пишите, пожалуйста, личные сообщения — не будем засорять комментарии. Спасибо.

Вступление


Джоэл Спольски в своей статье «Сглаживание шрифтов, анти-алиасинг и субпиксельный рендеринг» [1] (та же статья в переводе на Хабре, прим. перев.) сравнивает методы растеризации текста в продуктах Microsoft и Apple, и делает предположение, почему пользователи Windows не любят Safari. Он объясняет это тем, что текст в Safari выглядит черезмерно размытым. Я хочу пойти дальше и обобщить собственный опыт по этому вопросу. Я не эксперт в цифровой типографике, тем не менее, мне есть что сказать. Как минимум, некоторые из моих идей могут пригодиться сообществу GNU/Linux.

Джеф Этвуд в своем посте «Растеризация шрифтов: придерживаемся сетки пикселей» [5] пишет:

«Я не понимаю, почему Apple приносят настоящее в жертву будущему. Почему мы не можем пользоваться хинтингом на низких разрещениях, при этом соблюдая точность растеризации на высоких? Привязка шрифтов к сетке пикселей скорее всего будет неактуальной, когда каждый сможет наслаждаться великолепной картинкой на экране своего монитора разрешением в 200 DPI. Но до тех пор, пока это прекрасное время не настало, привязка к сетке пикселей однозначно делает текст значительно более читаемым для тех, кто живет в настоящем»

Я бы ответил на это, что до тех пор, пока Microsoft придерживается своей политики агрессивного хинтинга, мониторов с разрешением больше 100 DPI просто не появится. Стараниями Microsoft нам просто не вырваться из порочного круга.

Джеф не одобряет метод растеризации, применяющийся в продуктах Apple. Мне он тоже не слишком симпатичен. Но, может быть, миссия Apple как раз в том, чтобы приблизить эпоху 200 DPI мониторов? Ладно, моя планка ещё выше. Я хочу 300 DPI. Мне кажется, что даже 200 DPI недостаточно, чтобы полностью отказаться от хинтинга. Тем не менее, в этой статье я попробую осветить и стратегию Apple в том числе. Статья может показаться вам длинной и скучной, но я чувствую необходимость тщательно и детально проанализировать сложившуюся ситуацию.

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



Выглядит размытым? Но обратите внимание на размер текста. И имейте в виду, что он остается прекрасно читаемым, гладким и в то же время чётким. И в то же время, форма знаков полностью сохранена (используется гарнитура «Arial»).

Хорошо, как насчет этого примера?



Выглядит слишком тяжелым? Нет проблем, мы можем сделать его светлее.



И ещё пара примеров:





Это шрифт Georgia. Обратите внимание, форма знаков в обоих случаях идеально сохранена, просто во втором примере текст умышленно сделан более «тяжелым».

Но это была просто демонстрация, вот основная идея этой статьи: мы можем отказаться от привязки к пиксельной сетке по горизонтали! С этого момента вы можете использовать точность позиционирования текста по горизонтали в 1/256 пикселя! Вы можете сдвигать текст по горизонтали на любое дробное значение, при этом сохраняя прекрасный внешний вид текста! Эта «мелочь» на самом деле много значит. Как насчет этого:
  • Вы можете применять кернинг с субпиксельным разрешением, не заботясь о внесении дополнительного размытия.
  • Вы можете свободно масштабировать текст так, как вам захочется, со стопроцентной гарантией сохранения пропорций и отсутствия выпадения текста за границы графических элементов.
  • Вы всегда можете быть уверены в том, что расчетная ширина текста будет соответствовать тому, что вы увидите на экране и на бумаге.
  • Вы можете применять интересные векторные эффекты, такие как «искусственный полужирный» или «искусственный курсив», не рискуя получить при этом размытый текст.

Звучит как что-то невозможное? Хорошо, вот ещё один пример.



Посмотрите внимательно. Вы не заметили ничего странного? Каждая строка смещена вправо на одну десятую пикселя, так что в результате к 30-й строке смещение плавно накапливается, и составляет уже три пикселя. Я думаю, вы представляете себе, как бы выглядел этот пример, если бы мы использовали классическую привязку к сетке пикселей.

Если не представляете, вот пример:



Самое удивительное, что здесь нет ничего фантастически сложного! Даже патентовать нечего. Вся информация, которую я использовал, доступна публично и/или логически выводится из того, что мы знаем о применяющихся в настоящее время алгоритмах растеризации шрифтов. Вам всего лишь потребуется здравый смысл и немного инженерного чутья. Итак, поехали. Вы можете скачать демонстрационную программу со всеми исходниками в конце этой статьи, и поиграться с ней, но для начала, пожалуйста, проявите немного терпения, чтобы дочитать эту довольно длинную историю до конца.

Microsoft, Apple, Adobe и FontFocus


Я начну с довольно жесткого заявления. Microsoft сыграли злую шутку со всем остальным миром. Способ растеризации шрифтов в Windows XP представляет собой безвкусицу с полным отсутствием инженерной культуры. Текст в XP выглядит чётко и привлекательно, но при этом совершенно неправильно.

Небольшой тест. Представим, что у нас есть одна строка текста, набранная гарнитурой Times New Roman, и отпечатанная в высоком разрешении (допустим, ровно в 1000 DPI). Эта строка занимает на бумаге 87% некоторого заданного расстояния (предположим, 12,7 см). Теперь нам нужно получить пропорциональное изображение в низком разрешении, допустим, в 100 DPI так, чтобы наши 12,7 см соответствовали ровно 500 пикселям. Есть ли в Windows способ отобразить текст так, чтобы он занимал ровно 87% от 500 пикселей? Нет! Это очевидно из приведенных ниже скриншотов. Они сняты с Windows XP, «Свойства экрана -> Параметры -> Дополнительно -> Общие -> Масштаб (количество точек на дюйм) -> Особые параметры...».




Они (Microsoft. прим. перев.) пожертвовали честью инженеров ради денег, что привело к отсутствию технического прогресса (в повышении разрешения мониторов, прим. перев.) в течении многих лет. Они используют черезмерно агрессивный хинтинг, который не только искажает форму знаков, но и накапливает значительную ошибку (в координате по горизонтали, прим. перев.) на протяжении всей строки. В результате шрифты нельзя считать свободно масштабируемыми, они только выглядят масштабируемыми, но на самом деле это не так. Этот факт повлиял на индустрию компьютерных мониторов. Вы можете себе представить Windows XP на мониторе с разрешением в 600 DPI? Скажем, 8000x6000 пикселей? Я не могу, и не только из-за растровых пиктограмм, но преимущественно из-за ужасного масштабирования текста. Если вы измените разрешение в свойствах экрана, некоторые диалоговые окна в программах неизбежно будут отображаться некоректно. Соответственно, в чем мотивация выпускать мониторы с высоким разрешением?

Вы можете возразить, что проектировщики ПО должны учитывать различные размеры шрифта. Я бы согласился с вами, если бы не одна маленькая деталь. Создание стопроцентно корректных диалоговых окон чудовищно утомительно. В Windows Vista свободное масштабирование реализовано значительно лучше, но ситуация уже сложилась, и пройдет много времени, прежде чем она исправится. Другими словами, мы не можем свободно масштабировать диалоговые окна.

Некоторое время назад я работал на компанию Johnson&Johnson (привет Димитрису Аграфиотису и другим коллегам) и мне приходилось проектировать сложные диалоговые окна для платформы .Net WinForms. По умолчанию для любого статического или редактируемого текста применялось что-то вроде «Tahoma, 10pt». Но мне постоянно приходилось беспокоиться по поводу некоторого дополнительного свободного места в конце каждой строки текста, потому что после смены разрешения текст регулярно не вписывался в отведенное пространство, что приводило к тому, что формами совершенно невозможно было пользоваться. Так что если вы беспокоитесь о пропорциональном масштабировании, вам приходится оформлять ваши формы ужасным образом, оставляя большое количество свободного места «про запас». Другой способ заключается в том, чтобы жестко привязать размер текста к пикселям. То есть, использовать что-то вроде «Tahoma 14px» (обратите внимание, px, а не pt. прим. перев.). Это многое значит. Это значит, что ваше ПО не сможет использоваться на высоких разрешениях. Неважно, насколько хорошо Windows Vista поддерживает масштабирование текста: все равно беда уже случилась. Есть огромное количество ПО, которое полагается на фиксированное разрешение и это не дает производителям мониторов разрабатывать экраны высокого разрешения. Нет никакой мотивации! Вам не стоит обвинять меня и многих других разработчиков и проектировщиков ПО. Обвиняйте Microsoft за их брутальный хинтинг, который приводит к непредсказуемому наползанию текста на графические элементы.

Да, в Windows Vista с применением WPF всё становится свободно масштабируемым. Это хорошая новость. Плохая новость в том, что всё равно нельзя использовать высокие разрешения. Проблемы подробно описаны Лонгом Ценгом и Джимом Мэтьюсом:
Long Zheng, Windows Vista DPI scaling: my Vista is bigger than your Vista.
www.istartedsomething.com/20061211/vista-dpi-scaling
Jim Mathies, XP Style DPI Scaling.
www.mathies.com/weblog/?p=908

Microsoft и Adobe: субпиксельное позиционирование и кернинг

В Microsoft Word, который построен по принципу WYSIWYG, важно сохранять корректность разметки на любом разрешении. Это значит, что разметка должна быть свободно масштабируемой, и она действительно масштабируема. Но позвольте мне провести небольшое расследование. Ниже приведен текст так, как он выглядит в Microsoft Word из пакета Office 2003. Нет смысла читать этот текст, просто взгляните на него.



И сравните с тем, как он выглядит в Adobe Acrobat Reader:



Вы сможете лучше ощутить разницу, если скачаете оба изображения, и будете переключаться между ними в какой-нибудь программе, поддерживающей слайдшоу (я использую приятный и бесплатный IrfanView). Текст в Adobe Acrobat смотрится равномернее, к тому же, он гораздо ближе к тому, что мы видим на принтере. Текст в MS Word смотрится более чётким, но в целом он уродливее. Почему? Из-за кривого кернинга. Выглядит так, будто бы они вообще отказываются от кернинга на низких разрешениях (а 96 DPI это очень мало). Привязка глифов к пикселям в конечном итоге приводит к случайно разбросанным пробелам, которые выглядят просто ужасно. Есть только один способ заставить текст выглядеть лучше — использовать горизонтальное субпиксельное позиционирование. Это физический закон, близко связанный с теоремой Котельникова (в англоязычной литературе — теорема Найквиста — Шеннона или теорема отсчётов), которая гласит:

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

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

Пьер Арнауд продемонстрировал это ещё более понятным образом:

Положим, вам нужно вывести глиф для символа «i», который будет шириной точно в 2.4 пикселя. Если вы используете хинтинг, скорее всего, вы получите на выходе изображение шириной в 2 пикселя. Положим, что пробел у нас равен четырем пикселям.
Теперь представьте себе, что вам нужно вывести «iiiiiiiiii» (глиф «i» 10 раз). Это даст нам слово, которое занимает на экране 20 пикселей, но типографская позиция должна сдвинуться на 24 пикселя. Вам придется добавить 4 пикселя к последующему пробелу, что удвоит его размер. Это будет смотреться на экране довольно странно. Еще хуже будет, если глиф «i» реально занимает 2.6 пикселя, и хинтер решит растянуть его до 3 пикселей. В этом случае вы займете 30 пикселей на экране, хотя типографская позиция должна была сместиться на 26 пикселей. В этом случае, вы получите ошибку в -4 пикселя, и компенсация этой ошибки полностью съест последующий пробел.

Другая попытка могла бы заключаться в том, чтобы позиционировать глифы «i», округляя их типографские позиции, что привело бы нас к использованию следующих координат по оси x (в случае с шириной глифа в 2.4 пикселя):

x = 0 ----> 0   ошибка =  0      ширина = 2
x = 2.4 --> 2   ошибка = -0.4    ширина = 3
x = 4.8 --> 5   ошибка = +0.2    ширина = 2
x = 7.2 --> 7   ошибка = -0.2    ширина = 3
x = 9.6 --> 10  ошибка = +0.4    ширина = 2

Результат будет ужасен:

.*.*..*.*..*
............
.*.*..*.*..*
.*.*..*.*..*
.*.*..*.*..*
.*.*..*.*..*

Вы поняли идею… Интервалы между глифами «i» становятся переменными.

Да, становятся. Именно это и происходит в Microsoft Word.



Таким образом, Microsoft не допускает субпиксельное позиционирование, а Adobe допускает. Это значит, что одни и те же глифы на разных позициях могут давать разное фактическое отображение на экране. Это чётко заметно в слове «institutions», помеченном красным прямоугольником в примерах выше.





Взгляните на Adobe'овские глифы «i», «n», «s», «t». Есть как минимум две разные версии их отображения в разных позициях. Именно поэтому текст у Adobe смотрится более равномерным, но при этом более размытым.

Теперь, если вы наберете то же самое слово «institutions» в WordPad, результат будет другим (и будет смотреться куда лучше). Так почему же он так плохо выглядит в MS Word? Только из-за визуальной неточности в позиционировании. Функция TextOut(), которая, по-видимому, используется в WordPad, не заботится об этом, но MS Word вынужден (чтобы сохранять корректность разметки при масштабировании, прим. перев.). Я не уверен на все сто, но могу предположить, что разработчики MS Word расчитывают смещение глифов на высоких разрешениях с нехинтованными глифами. Есть только один способ сделать это, используя документированный Win32 API — вызвать GetGlyphOutline() с очень сильно увеличенной аффинной матрицей таким образом, чтобы получившийся глиф умещался в прямоугольник 1024x1024 или около того. Непосредственное использование этого приема дает точно такой же результат, как и TextOut(). Он смотрится хорошо, но накапливает ощутимую ошибку на протяжении строки текста (больше, чем размер одного символа на протяжении только одного слова!).

В случае же с диалоговыми окнами, как мне кажется, они решили допустимым не сохранять точную ширину текста. Почему? Потому что иначе подписи, меню, диалоговые окна и тому подобное не выглядели бы так заманчиво. Была бы та же самая проблема со случайно разбросанным кернингом, что явно навредило бы продажам их ПО. Итак, симпатичный и чёткий текст в диалоговых окнах способствует бизнесу, но накапливает значительную неточность в ширине текста, что приводит к невозможности изменения размера диалоговых окон, что в свою очередь вынуждает производителей выпускать мониторы с 96 DPI — в результате мы имеем порочный круг, который в конце концов превратился в большую профанацию.

С чисто инженерной точки зрения должен быть разумный компромисс между чёткостью текста и функциональностью. Проблема в том, что Microsoft сконцентрировалась на гламурном оформлении, при этом полностью игнорируя функциональную часть. Парадокс в том, что на разрешении в 300 DPI вам вообще не нужен хинтинг, к тому же, текст становится свободно масштабируемым (а при разрешении 600 DPI и выше вам даже не нужен анти-алиасинг). Но вы не можете использовать ваше ПО на 300 DPI, потому что оно расчитано в лучшем случае на 100 DPI! Вот цена, которую весь мир платит за гламурное оформление. Эта цена слишком высока, просто невероятно высока.

Несмотря на это, ещё 5 (пять!) лет назад было технически возможно иметь свободно масштабируемые формы и диалоговые окна. Все, что нам было нужно — допустить определенную степень размытия, очень незначительную, не настолько высокую, как в Mac OS X. Скорее, как в продукции Adobe. Пользователи Windows не любят Safari за слишком размытый вывод. Я частично согласен с ними, за исключением слепого отрицания любых других способов растеризации, кроме того, что применяется в Windows. Это просто безрассудный фанатизм. Это всё равно, что сказать «мне плевать на разрешение, всё, что я хочу это чтобы Windows выглядела так, как я привык, даже ценой в 96 DPI навсегда, даже если для этого потребуется остановить технический прогресс». Можно ли считать такой взгляд разумным?

Я не агитирую в пользу Apple, так как от растеризации Apple я тоже не в восторге. На мой взгляд, она действительно выглядит черезмерно размытой. Похоже что они используют что-то вроде алгоритма автохинтинга, который размывает горизонтальные штрихи, но по сути не дает никаких преимуществ. Фактически, их хинтинг тоже выглядит кривым, особенно для шрифтов без засечек, как будто бы они специально сдвинули чёткий текст на 0,2..0,5 пиксела. Именно поэтому пользователи Windows так не любят Safari. Но при этом многие из них с удовольствием используют Adobe Acrobat Reader и остаются довольны. Всё потому, что в нём текст выглядит приемлимо (не идеально, но приемлимо для фанатов Windows). При этом он остается свободно масштабируемым! Попробуйте просто загрузить любой документ и плавно увеличивать-уменьшать его. Разметка текста остается корректной, и при этом кернинг тоже. Так что я бы назвал способ рендеринга Adobe наилучшим, потому что их компромисс выглядит очень близко к оптимальному.

Субпиксельное позиционирование с помощью ClearType: возможно ли?

Джеф Этвуд однозначно голосует [5] за строгую привязку к пиксельной сетке. У меня свое мнение. Я согласен считаться с пиксельной сеткой, но только по оси Y. По X предпочтительнее использовать субпиксельное позиционирование. При этом мы жертвуем резкостью (но совсем незначительно), зато обретаем полную свободу.

Ирония в том, что у Microsoft уже есть субпиксельное позиционирование в хинтинге глифов. Самое смешное в том, что это чётко видно на страницах Джефа с тем шрифтом, который он использует.



Посмотрите внимательно: слово «common», выделенное красным, а также буква «m».



Видите, три вертикальных штриха «m» отличаются друг от друга! Несмотря на это, в оригинальном тексте они смотрятся вполне чётко и привлекательно. Что это значит? Многое. Это значит, что с ClearType возможно использовать позиционирование с точностью до 1/3 пикселя. В таком случае, зачем они прикрепляют глифы к пикселям?! Этого я не понимаю. Точности в 1/3 пикселя было бы достаточно для точного кернинга и одновременно чёткого текста! Хорошо, если я вас ещё не убедил, продемонстрирую в деталях. Я взял скриншот строки текста из Microsoft Word. Он выглядел так:



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



А затем я произвел «альфа-смешивание» этой карты в модели цветов RGB, воспринимая каждый цветовой канал как отдельный серый пиксель. Я проделал это 12 раз со смещением в 1 серый пиксель, что давало смещение на 1/3 пикселя в RGB. Посмотрите, что получилось:



Но это же и есть субпиксельное позиционирование! Вы можете легко убедиться в этом: за 12 линий накопились 4 лишних пикселя, при этом чёткость символов не пострадала. Хорошо, строки слегка отличаются, но вам придется очень близко рассматривать их, чтобы это заметить (замечу, что у меня зрение — единица, и я не ношу очки). Поверьте мне, это очень низкая цена за свободу точного субпиксельного позиционирования! Так что это работает. Это вполне возможно. Почему вы не используете субпиксельное позиционирование, дорогая Microsoft, ответьте! Ответа нет.


Кстати, а есть ли субпиксельное позиционирование в Windows Vista? Похоже что нет. Во всяком случае, я не смог найти ни одного примера, чтобы один и тот же глиф растеризовался в различные наборы пикселей в разных позициях. Вы видите, они слегка увеличили размер шрифта по умолчанию (для 96 DPI), но, что более заметно, они увеличили межсимвольные интервалы таким образом, чтобы некорректное позиционирование было менее заметно. Это хорошо, но как насчет более аккуратных форм символов? Да, вынужден признать, что ситуация с цифровой типографикой не слишком улучшилась после выхода Vista. И вряд ли мы можем расчитывать, что в ближайшее время она изменится.

Ещё один большой вопрос заключается в названии «Microsoft ClearType Font Collection». Почему они называют её коллекцией шрифтов ClearType? Эта технология жёстко привязана к конкретным шрифтам? Тогда, опять же, эта технология производит впечатление очень узкоспециализированного локального решения, таким образом, она не может быть успешно применена к абсолютно любому шрифту. Ниже я продемонстрирую, что с применением автохинтера FreeType вполне возможно получить честный, универсальный и независимый от шрифта способ растеризации. Всё, что вам нужно, это векторные кривые глифов. Больше ничего.

Способ, которым FontFocus выполняет выравнивание по сетке пикселей

Джеф среди всего прочего ссылается на документацию к FontFocus [4]. При всем уважении, я вынужден не согласиться с ней.


Они выравнивают штрихи по пикселям, игнорируя при этом вертикальный хинтинг. Вы видите, символы «T», «W», «C» и «g» сильно размыты. Кроме того, «W» выглядит тяжелее остальных.

На мой взгляд, это выглядит довольно небрежно. Подразумевается, что это Times New Roman. Похоже? Нет, больше похоже на примитивный растровый шрифт. Так в чем же смысл? Не проще ли один раз сохранить шрифт как растровый и использовать на низких разрешениях его? Какой смысл в анти-алиасинге, если мы можем себе позволить искажать форму знаков? Кроме того, похоже что в тексте есть «пятна», будто бы он написан чернилами на мягкой салфетке: большая часть штрихов правильные, но кое-где они смазаны. В любом случае, проблема та же: либо вы отказываетесь от корректной разметки, либо получаете кривой кернинг.

Здесь я хочу снова упоминуть Safari. Не могу сказать с полной уверенностью, но похоже, что Mac OS тоже не использует субпиксельный кернинг, что в итоге приводит к тем же проблемам, о которых я уже писал выше, критикуя Microsoft. Способ Safari гораздо ближе к тому, чтобы получить корректную разметку и при этом сохранять правильное позиционирование знаков. Но выглядит так, будет бы они тоже жестко привязывают символы к пикселям, не важно, насколько размытым получается результат. Так в чем же их политика? Специально использовать растеризацию, которая дает размытый текст, только для того, чтобы люди покупали экраны с более высоким разрешением? Нечестная игра!

Ниже вы увидите, как добиться приятного и корректного отображения текста, и, что самое интересное, в результате весьма простых манипуляций. Я использовал библиотеку FreeType [10] и функцию GetGlyphOutline() из Win32 API. Другими словами, такая схема растеризации возможна как в Windows, так и в Linux, ну и конечно же в Mac OS, в которой FreeType тоже прекрасно компилируется. Кроме того, я выяснил, что авто-хинтер FreeType работает вполне корректно, если использовать его так, как я это делал (в обычных условиях результат его работы нельзя назвать приемлимым). Но для начала я расскажу о ситуации в мире Linux.

Продолжение...
Перевод: Maxim Shemanarev
Иван Сорокин @unxed
карма
112,1
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Дизайн

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

  • +6
    Написал комментарий, смотрю, нет комментария и половины статьи заодно. Нифигасе откоментил подумал Штирлиц… Оказалось автор разделил ее на две части в это время. А если серьезно, спасибо еще раз за этот труд, обрывочные знания на тему, почему же шрифты ШГ, упорядочились и пришло чуть ли не просветление.
    • +1
      Ну, по большей части спасибо всё-таки автору. А разрезать пришлось, потому что я сначала не учёл лимит на размер топика на Хабре.
  • +13
    Вот какими должны быть статьи.
    • +6
      А какими должны быть гонорары за такие статьи?
      • –15
        думаю, равными нулю.
      • +3
        Лучшим гонораром (как мне, так и автору) в данном конкретном случае было бы, если бы кто-нибудь довел описанный в статье алгоритм до состояния реального продукта, желательно, открытого :-) Например, в виде патча к LibreOffice, Sumatra PDF… да хотя бы к тем же GTK+/Qt!
        • 0
          не нужно патчить gtk — она шрифтами не занимается. там используется pango, которая для растеризации использует freetypе )
          • 0
            Значит, патчить надо pang. Сам freetype не умеет делать хинтинг только по вертикали.
        • 0
          >сли бы кто-нибудь довел описанный в статье алгоритм до состояния реального продукта, желательно, открытого

          antigrain открыт и даже много где используется
  • +5
    Есть ещё одна проблема с субпиксельным позиционированием шрифтов, когда компьютеры были послабее. Если мы выводим символы с привязкой к пикселю, то можем сделать фиксированный набор рисунков символов и затем быстро выводить его, рассматривая как спрайты. Не в последнюю очередь это обуславливает быстроту вывода сотен страниц в Ворде. Можно было, конечно, сделать и 3 набора со сдвигом на 1/3 пикселя, но тогда почему не 4? Или 5/2? А ворд когда закладывали? Во времена 1983-1987 (версии 1-3). Тогда было совсем не до мониторов с 300 dpi :). Тогда важно было, чтобы 8086 мало-мальски справился с хинтингом и керниногом.
    • +3
      В конце второй части автор как раз предлагает кэшировать спрайты. Да, объем памяти под кэш при использовании субпиксельной растеризации больше в три раза, но до появления LCD панелей она была и не нужна, а когда они появились, подобные затраты памяти уже не являлись критичными.
  • 0
    Поправьте WISIWIG на WYSIWYG.
    • 0
      Ага.
  • 0
    Хорошая статья. В оригинал бы ещё разоблачение кривизны при отрисовке горизонтальных элементов шрифтов…
  • +2
    Статья хорошая.
    Но зачем же так с word'ом обошлись, верхний кусок (из word'а) — без переносов, нижний — с переносами. Конечно он будет выглядеть лучше при такой выключке
    На самом деле все не так плохо, как здесь показано
    • +3
      Думаю автор просто поленился или не смог сделать скриншоты с одинаковой выключкой, т.к. сравнивается кернинг в отдельном слове а не ширина пробелов между словами. А насчет связи хинтинга и производства мониторов, автор, конечно перегнул.
  • +5
    будущее уже здесь, у iphone 4 — 326 PPI, и благодаря этому он отлично рендерит текст
    • +3
      Apple всегда, кстати, ставили на свои продукты мониторы с бОльшим разрешением, чем в среднем по рынку. То есть опциональные 1900x1200 на их 17-дюймовых ноутах были тогда, когда стандартм был еще 1280x900 или что-то вроде.

      и т.п.
    • +1
      На новом макбуке эире (с диагональю 11,6 дюймов который) около 135 ППИ
      Десктопы дольше будут идти к трём сотням.
      Заинтересовавшись этой темой нашёл калькулятор PPI.

      Будет забавно, если десктопы дорастут до 300, а мобильники к этому времени уже приблизятся к 600 и там не нужен будет анти-алиасинг.
  • 0
    IrfanView не свободный, а бесплатный. Исправьте, пожалуйста.
    • 0
      Да, ещё слово accurate переводится как «точный», а не «аккуратный».
      • 0
        В зависимости от контекста, не?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Fixed.
  • +2
    Очень странно видеть перевод статьи русскоязычного автора.
  • +2
    Почти общесистемная замена ClearType на Freetype в Windows: code.google.com/p/gdipp/
    • 0
      Спасибо, интересная штука. Буду смотреть.
    • 0
      Идея отличная, а реализация всё-таки пока далека от совершенства. Меня, например, в корне не устраивают такие вещи:


      Ведь дело не только в том, чтобы рендерить через фритайп, важно ещё сохранять длину строк и кернинг. В общем, нужно разбираться, откуда лезут косяки и писать багрепорты.
      • 0
        Впрочем, возможно, я слегка погорячился. Возьмем, к примеру, древний Word 97 на XP. На мой взгляд, результат gdipp в любом случае сильно лучше оригинального gdi. В примерах — плавное увеличение кегля от 5 до 18.

        gdi
        gdipp

        Обратите внимание на издевательства над «е», «ё» и «ф» в оригинальном растеризаторе.
        • 0
          А вот в Wordpad всё та же ересь с длинами строк. Почему? Потому что совместимость. Вот об этом автор статьи и пишет… :'-(

          Пример.
          • 0
            Написал багрепорт. Интересно, возможно ли это поправить, не сломав все стандартные формы…
    • 0
      Посмотрел документацию. Там всё-таки нельзя включать хинтинг только по горизонтали. А так бы хотелось, чтоб было можно!
  • +2
    Просто windows нужно было с самого начала идти по пути java — использовать лайауты. Тогда неточность в ширине текста никого не волнует — диалоговые окна растянутся/сожмутся автоматически до нужного размера. При этом, конечно, в лайатуах по-прежнему будут использоваться пиксели для указания отступов и других менее важных размеров. Но по крайней мере не будет вылезания текста за границы отведенного поля, которое я постоянно наблюдаю.
    • +2
      В Microsoft вообще много где «пошли своим путем» (с).
    • +1
      Вероятно, мощности PC образца конца 80-х-начала 90-х не хватало на динамическое вычисление размеров формы и её элементов.
      • +1
        Вероятно, сейчас не конец 80-х. 20 лет прошло. Давайте ещё наследие 50-х годов тянуть. =)
        • 0
          очень хочу иметь на крышке своего ноутбука набор лампочек. И чтоб они еще и светились :) А желательно чтобы еще и работали. И чтоб если онда вдруг перегорает — ком бы зависал. Ня же :)
      • +2
        Динамическое вычисление размеров формы не сильно сложнее расчета длины строки на экране. По сравнению с прорисовкой это очень небольшое время.

        Тут нужно еще учесть, что в windows в то время использовался механизм ресурсов. При такой механике, в ресурсы нельзя было бы поместить свои лайауты. А стандартные лайауты должны были бы обрабатываться ОС, что не удобно. Если бы вместо этого была бы выбрана чисто пользовательская технология (VCL/MFC), то с лайаутами проблем бы не было. А так технология ресурсов отравила и технологии VCL/MFC/(Windows Forms?) :(.
  • +1
    При том, что я признаю важность сглаживания шрифтов для задач масштабирования и т.д., и т.п., лично мне всегда было на порядок удобнее читать вообще без сглаживания. Поэтому оно у меня везде выключено :)
    • +1
      Привычка. Включите сглаживание — через неделю на шрифты без сглаживания смотреть не сможете.
      • –1
        Фигня. Включаю сглаживание, минут 20 работаю, и больше просто не могу: глаза слишком устают в попытках поймать фокус. Может, скажу сейчас глупогадость: но размытые шрифты хорошо воспринимаются людьми с плохим зрением. Если же у человека зрение хорошее и он привык видеть чётко, то размытие — это насилие над его зрением. Когда на экране один текст, и нет спасительных чётких изображений (как при работе в текстовом редакторе или в терминале), то глаза выносит моментально.
        • +2
          У меня зрение — идеально. Вы работаете 20 минут. И испытываете дискомфорт из-за непривычки. Вы поработайте неделю, а потом сравните.

          Возможно, наоборот. Когда зрение плохое — шрифты и так мылятся, потому можно не сглаживать.
          • 0
            Так как мне работать, если я читать не могу? То есть, могу, конечно, но через силу и с большим дискомфортом. Неделю я так не выдержу. И это ещё учтите, что сейчас я пишу диссертацию, в TeX, естественно, и поэтому гляжу в размытые Adobe'ом шрифты довольно долго в течении дня. Поэтому, привычка, вроде как, есть. Но когда на экране всё становится размытым — и редактор и PDF'ка, то всё, глаза в кучу, никакого удобства. Я не привыкну к этому. Ну, или, может тогда, когда пиксели на мониторах станут настолько мелкими, что я не буду различать эти облачка серости вокруг основных контуров. Например, на электронной бумаге я этого не различаю настолько, чтобы оно вызывало неудобство. Но на электронной бумаге и без размазывания шрифты смотрятся замечательно.
  • +2
    > Почему вы не используете субпиксельное позиционирование, дорогая Microsoft, ответьте! Ответа нет.

    Ответ очевиден. Все дело в API. GDI32 использует пиксельную привязку к координатам. Поэтому и позиционировать по строке, например курсор, можно только в целых числах. Современные графические библиотеки, в том числе и GDI+, уже давно используют дробную арифметику, но видимо всплыли проблемы с совместимостью со старыми API, либо GDI+ просто лежит леером поверх старого GDI32.
  • –1
    А меня вот размытые шрифты утомляют. И глаза от них болят. БррРрр! Сделайте нормальный aliasing-рендеринг! (ходит с транспорантом). Нет, оно, конечно, понятно, что близость к принтеру, равномерность, бла-бла-бла. Но, ёлки, у меня нет принтера. Я не замечают неравномерностей в один микрометр. Я просто хочу читать чёткий и одноцветный текст с экрана. А мне вечно стремятся подсунуть какую-то размазанную ерунду вместо качественного pixel-рендеринга.
  • –2
    Очень интересная статья, но замечание про то, что майкрософтовская растеризация шрифтов тормозит технический прогресс, ей-богу, посмешило. Вообще-то, при увеличении разрешения с 96 dpi до 300 dpi, число пикселов на экране возрастет в 10 раз, а, значит, для хранения и обработки изображения понадобится в 10 раз больше памяти и в 10 раз больше вычислительных мощностей. Полагаю, решить эту задачу будет посложнее, чем изменить алгоритм растеризации.
    • 0
      Это кто это вам сказал, что «понадобится в 10 раз больше памяти и в 10 раз больше вычислительных мощностей»? Плюньте в него, это ересь.
      • 0
        Почему понадобится в 10 раз больше памяти, вполне очевидно. Любая векторная графика, прежде чем попадет на экран монитора, превращается в bitmap (заметьте, кстати, слово «растеризация» в заголовке). А чтобы обработать больший объем информации, понятно, нужны большие трудозатраты. Ни разу не видели, как какая-нибудь 3D-игруха, казалось бы, при незначительном увеличении разрешения, начинает значительно подтормаживать?
        Лучше объясните, почему думаете, что не понадобится?
        • 0
          Скажите, а электричества тоже в 10 раз больше понадобится? Не думайте, я не ёрничаю.
          • 0
            Разумеется. Я про электричество, потребляемое процессором непосредственно на обработку графики, не про подсветку дисплея :)
            Так все-таки, какие вы предлагали альтернативы алгоритмам заливки, тайлинга, двойной буферизации, наконец, растеризации шрифтов, сложность которых будет о-малым от dpi^2 и по памяти, и по количеству операций? Мне вдвойне интересно, поскольку одно время наша команда в Sun Microsystems занималась оптимизацией графики внутри Java ME платформы, и приходилось не раз сталкиваться с тем, что при увеличении разрешения дисплея, скажем 240x320 -> 480x640, стандартные алгоритмы начинали работать в 4 раза медленнее или занимать в 4 раза больше памяти. Поэтому приходилось прибегать к компромиссам и всяким трюкам вроде наборов тайлов разного размера, компиляции шрифтов и т.п.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    На скриншоте со смещением текста «A single pixel on a color LCD is made of three colored elements» на 1/3 пикселя я чётко вижу карусель из трёх цветов, по цвету на каждую строку.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Уродливые шрифты способствуют запоминанию содержания.
    • +1
      Возможно. Но запоминание как «зазубривание» и усвоение информации как «понимание» — это разные вещи. Второе измерить сложнее.
  • 0
    Сравнение скриншотов Word и Adobe Reader очевидно некорректно — вся разница из-за того что последний использует разбиение на слоги. Почему автор предпочёл не замечать этот факт и стоит ли после такого продолжать чтение — вопрос.

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