Pull to refresh

Comments 60

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

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

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

Будет забавно, если десктопы дорастут до 300, а мобильники к этому времени уже приблизятся к 600 и там не нужен будет анти-алиасинг.
IrfanView не свободный, а бесплатный. Исправьте, пожалуйста.
Да, ещё слово accurate переводится как «точный», а не «аккуратный».
В зависимости от контекста, не?
UFO just landed and posted this here
Очень странно видеть перевод статьи русскоязычного автора.
Спасибо, интересная штука. Буду смотреть.
Идея отличная, а реализация всё-таки пока далека от совершенства. Меня, например, в корне не устраивают такие вещи:


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

gdi
gdipp

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

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

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

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

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