Comments 60
Написал комментарий, смотрю, нет комментария и половины статьи заодно. Нифигасе откоментил подумал Штирлиц… Оказалось автор разделил ее на две части в это время. А если серьезно, спасибо еще раз за этот труд, обрывочные знания на тему, почему же шрифты ШГ, упорядочились и пришло чуть ли не просветление.
Вот какими должны быть статьи.
А какими должны быть гонорары за такие статьи?
думаю, равными нулю.
Лучшим гонораром (как мне, так и автору) в данном конкретном случае было бы, если бы кто-нибудь довел описанный в статье алгоритм до состояния реального продукта, желательно, открытого :-) Например, в виде патча к LibreOffice, Sumatra PDF… да хотя бы к тем же GTK+/Qt!
Есть ещё одна проблема с субпиксельным позиционированием шрифтов, когда компьютеры были послабее. Если мы выводим символы с привязкой к пикселю, то можем сделать фиксированный набор рисунков символов и затем быстро выводить его, рассматривая как спрайты. Не в последнюю очередь это обуславливает быстроту вывода сотен страниц в Ворде. Можно было, конечно, сделать и 3 набора со сдвигом на 1/3 пикселя, но тогда почему не 4? Или 5/2? А ворд когда закладывали? Во времена 1983-1987 (версии 1-3). Тогда было совсем не до мониторов с 300 dpi :). Тогда важно было, чтобы 8086 мало-мальски справился с хинтингом и керниногом.
Поправьте WISIWIG на WYSIWYG.
Хорошая статья. В оригинал бы ещё разоблачение кривизны при отрисовке горизонтальных элементов шрифтов…
Статья хорошая.
Но зачем же так с word'ом обошлись, верхний кусок (из word'а) — без переносов, нижний — с переносами. Конечно он будет выглядеть лучше при такой выключке
На самом деле все не так плохо, как здесь показано
Но зачем же так с word'ом обошлись, верхний кусок (из word'а) — без переносов, нижний — с переносами. Конечно он будет выглядеть лучше при такой выключке
На самом деле все не так плохо, как здесь показано
будущее уже здесь, у iphone 4 — 326 PPI, и благодаря этому он отлично рендерит текст
Apple всегда, кстати, ставили на свои продукты мониторы с бОльшим разрешением, чем в среднем по рынку. То есть опциональные 1900x1200 на их 17-дюймовых ноутах были тогда, когда стандартм был еще 1280x900 или что-то вроде.
и т.п.
и т.п.
На новом макбуке эире (с диагональю 11,6 дюймов который) около 135 ППИ
Десктопы дольше будут идти к трём сотням.
Заинтересовавшись этой темой нашёл калькулятор PPI.
Будет забавно, если десктопы дорастут до 300, а мобильники к этому времени уже приблизятся к 600 и там не нужен будет анти-алиасинг.
Десктопы дольше будут идти к трём сотням.
Заинтересовавшись этой темой нашёл калькулятор PPI.
Будет забавно, если десктопы дорастут до 300, а мобильники к этому времени уже приблизятся к 600 и там не нужен будет анти-алиасинг.
IrfanView не свободный, а бесплатный. Исправьте, пожалуйста.
Очень странно видеть перевод статьи русскоязычного автора.
Почти общесистемная замена ClearType на Freetype в Windows: code.google.com/p/gdipp/
Спасибо, интересная штука. Буду смотреть.
Идея отличная, а реализация всё-таки пока далека от совершенства. Меня, например, в корне не устраивают такие вещи:
Ведь дело не только в том, чтобы рендерить через фритайп, важно ещё сохранять длину строк и кернинг. В общем, нужно разбираться, откуда лезут косяки и писать багрепорты.
Ведь дело не только в том, чтобы рендерить через фритайп, важно ещё сохранять длину строк и кернинг. В общем, нужно разбираться, откуда лезут косяки и писать багрепорты.
Впрочем, возможно, я слегка погорячился. Возьмем, к примеру, древний Word 97 на XP. На мой взгляд, результат gdipp в любом случае сильно лучше оригинального gdi. В примерах — плавное увеличение кегля от 5 до 18.
gdi
gdipp
Обратите внимание на издевательства над «е», «ё» и «ф» в оригинальном растеризаторе.
gdi
gdipp
Обратите внимание на издевательства над «е», «ё» и «ф» в оригинальном растеризаторе.
Посмотрел документацию. Там всё-таки нельзя включать хинтинг только по горизонтали. А так бы хотелось, чтоб было можно!
Впрочем, попытка — не пытка.
Просто windows нужно было с самого начала идти по пути java — использовать лайауты. Тогда неточность в ширине текста никого не волнует — диалоговые окна растянутся/сожмутся автоматически до нужного размера. При этом, конечно, в лайатуах по-прежнему будут использоваться пиксели для указания отступов и других менее важных размеров. Но по крайней мере не будет вылезания текста за границы отведенного поля, которое я постоянно наблюдаю.
В Microsoft вообще много где «пошли своим путем» (с).
Вероятно, мощности PC образца конца 80-х-начала 90-х не хватало на динамическое вычисление размеров формы и её элементов.
Вероятно, сейчас не конец 80-х. 20 лет прошло. Давайте ещё наследие 50-х годов тянуть. =)
Динамическое вычисление размеров формы не сильно сложнее расчета длины строки на экране. По сравнению с прорисовкой это очень небольшое время.
Тут нужно еще учесть, что в windows в то время использовался механизм ресурсов. При такой механике, в ресурсы нельзя было бы поместить свои лайауты. А стандартные лайауты должны были бы обрабатываться ОС, что не удобно. Если бы вместо этого была бы выбрана чисто пользовательская технология (VCL/MFC), то с лайаутами проблем бы не было. А так технология ресурсов отравила и технологии VCL/MFC/(Windows Forms?) :(.
Тут нужно еще учесть, что в windows в то время использовался механизм ресурсов. При такой механике, в ресурсы нельзя было бы поместить свои лайауты. А стандартные лайауты должны были бы обрабатываться ОС, что не удобно. Если бы вместо этого была бы выбрана чисто пользовательская технология (VCL/MFC), то с лайаутами проблем бы не было. А так технология ресурсов отравила и технологии VCL/MFC/(Windows Forms?) :(.
При том, что я признаю важность сглаживания шрифтов для задач масштабирования и т.д., и т.п., лично мне всегда было на порядок удобнее читать вообще без сглаживания. Поэтому оно у меня везде выключено :)
Привычка. Включите сглаживание — через неделю на шрифты без сглаживания смотреть не сможете.
Фигня. Включаю сглаживание, минут 20 работаю, и больше просто не могу: глаза слишком устают в попытках поймать фокус. Может, скажу сейчас глупогадость: но размытые шрифты хорошо воспринимаются людьми с плохим зрением. Если же у человека зрение хорошее и он привык видеть чётко, то размытие — это насилие над его зрением. Когда на экране один текст, и нет спасительных чётких изображений (как при работе в текстовом редакторе или в терминале), то глаза выносит моментально.
У меня зрение — идеально. Вы работаете 20 минут. И испытываете дискомфорт из-за непривычки. Вы поработайте неделю, а потом сравните.
Возможно, наоборот. Когда зрение плохое — шрифты и так мылятся, потому можно не сглаживать.
Возможно, наоборот. Когда зрение плохое — шрифты и так мылятся, потому можно не сглаживать.
Так как мне работать, если я читать не могу? То есть, могу, конечно, но через силу и с большим дискомфортом. Неделю я так не выдержу. И это ещё учтите, что сейчас я пишу диссертацию, в TeX, естественно, и поэтому гляжу в размытые Adobe'ом шрифты довольно долго в течении дня. Поэтому, привычка, вроде как, есть. Но когда на экране всё становится размытым — и редактор и PDF'ка, то всё, глаза в кучу, никакого удобства. Я не привыкну к этому. Ну, или, может тогда, когда пиксели на мониторах станут настолько мелкими, что я не буду различать эти облачка серости вокруг основных контуров. Например, на электронной бумаге я этого не различаю настолько, чтобы оно вызывало неудобство. Но на электронной бумаге и без размазывания шрифты смотрятся замечательно.
> Почему вы не используете субпиксельное позиционирование, дорогая Microsoft, ответьте! Ответа нет.
Ответ очевиден. Все дело в API. GDI32 использует пиксельную привязку к координатам. Поэтому и позиционировать по строке, например курсор, можно только в целых числах. Современные графические библиотеки, в том числе и GDI+, уже давно используют дробную арифметику, но видимо всплыли проблемы с совместимостью со старыми API, либо GDI+ просто лежит леером поверх старого GDI32.
Ответ очевиден. Все дело в 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 раза больше памяти. Поэтому приходилось прибегать к компромиссам и всяким трюкам вроде наборов тайлов разного размера, компиляции шрифтов и т.п.
Так все-таки, какие вы предлагали альтернативы алгоритмам заливки, тайлинга, двойной буферизации, наконец, растеризации шрифтов, сложность которых будет о-малым от 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
Сравнение скриншотов Word и Adobe Reader очевидно некорректно — вся разница из-за того что последний использует разбиение на слоги. Почему автор предпочёл не замечать этот факт и стоит ли после такого продолжать чтение — вопрос.
Я просто оставлю это здесь:
Sign up to leave a comment.
Разоблачение алгоритмов растеризации шрифтов (1/2)