Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Apr 24, 2019 6:02 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 33 posts ]  Go to page Previous 1 2 3 Next
Author Message
PostPosted: Sun Aug 04, 2013 1:41 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Чтобы не быть голословным, вот картинка из W7 с отключенным сглаживанием:
Attachment:
w7_font_nonsmooth_small.png
w7_font_nonsmooth_small.png [ 1.29 KiB | Viewed 2805 times ]

И чтобы проще было смотреть увеличенная картинка:
Spoiler: Show
Attachment:
w7_font_nonsmooth.png
w7_font_nonsmooth.png [ 7.98 KiB | Viewed 2805 times ]

Смею заметить - никаких переходных цветов и полутонов. Это больше похоже на реализацию шрифтов сделанную art_zh
Image
Image
Image

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Sun Aug 04, 2013 2:07 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Чтобы не было вопросов к тому что растеризован маленький размер шрифта, то вот растеризация для большого размера.
Attachment:
moooore_small.png
moooore_small.png [ 5.01 KiB | Viewed 2803 times ]

А вот увеличенное изображение:
Spoiler: Show
Attachment:
moooore.png
moooore.png [ 51.13 KiB | Viewed 2803 times ]

И снова - все буквы одного порядка имеют одинаковую высоту и никаких переходов и полутонов. Выглядит все же вполне приемлемо.

Так как же получается, что в предлженной картинке буквы одного порядка скачут по высоте?

Авторы свободной реализации шрифта были
Spoiler: Show
"так верстают только мудаки" Дизайнер Всея РФии Артемий Татьяныч.

сильно ленивыми или все же растеризатор для несглаженного вывода глючит?

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

Я в zSea, когда делал плагин для масштабирования, то тупо учитывал по математическому правилу округления. Например, при делении DIV в EDX остается остаток. Я его битовым сдвигом умножаю на 2 и сравниваю с делителем. Если результат равен или больше делителя, то результат деления инкрементируется на единицу, если меньше, то результат остается как есть. Это уже позволяет добиться приемлемой точности результата для вывода на экран.
Spoiler: Show
Между прочим у меня всего лишь средне-техническое образование и ВУЗ я не заканчивал. :wink:

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Sun Aug 04, 2013 5:53 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Mario: http://ru.wikipedia.org/wiki/%D5%E8%ED%F2%E8%ED%E3
Я же сказал, это без хинтинга. Алгоритм хинтинга - штука сложная.
Без него получается именно такое: либо дырки в буквах, либо размер букв скачет. Вот попробуй взять букву ООГРОМНОГО размера, а затем уменьшить без сглаживания - будет то самое, что без хинтинга.


Top
   
PostPosted: Sun Aug 04, 2013 6:04 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Ну - вариант рендера без хинтинга, и без контроля отсечки:
Attachment:
no hint.png
no hint.png [ 1.71 KiB | Viewed 2785 times ]

Сверху надпись, снизу она же - но уменьшенная. Если алгоритм контроля отсечки отключен, без сглаживания при маленьких размерах шрифта в тексте будут "дыры". При использовании относительно несложного алгоритма контроля отсечки в тех местах, где толщина линии менее 1 пиксела, все равно ставится 1 пиксел. В итоге высота букв прыгает.
Зубцы по краям букв - отвратительно.

Другое дело, если выкрутить хинтинг на максимум.
Attachment:
fullhint.png
fullhint.png [ 1.61 KiB | Viewed 2785 times ]


Но это уже намного более сложные и трудные для вычисления вещи. Сглаживание попроще будет.


Top
   
PostPosted: Sun Aug 04, 2013 6:09 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Image
Соответственно, оригинальный глиф (справа), и то, что с ним делает алгоритм хинтинга, чтобы "ничего не прыгало" (слева)


Top
   
PostPosted: Sun Aug 04, 2013 6:40 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
SoUrcerer wrote:
Я же сказал, это без хинтинга. Алгоритм хинтинга - штука сложная.

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

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Sun Aug 04, 2013 8:02 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Ты не можешь отключить хинтинг. Хинтинг - это НЕ сглаживание, хинтинг - это изменение ФОРМЫ буквы, для того, чтобы она попадала в сетку пикселей. В Microsoft Windows используется __агрессивный хинтинг__, то есть форма буквы меняется очень и очень значительно для того, чтобы на маленьких размерах символы выглядели читабельными.
Графический редактор GIMP позволяет отключить хинтинг в инструменте "редактирование текста" - равно как и photoshop. Однако, GIMP не представляет возможности отключить контроль отсечки пикселей. Для неверующих записал видео, выкладываю в сеть пока что - но ничего интересного в нем нет, я просто добавляю надпись, убираю сглаживание, и меняю разные настройки хинтинга для разных размеров. Затем включаю сглаживание, меняю настройки хинтинга. Затем отключаю сглаживание, и эмулирую отсутствие "контроля отсечки" - беру большую растровую картинку и уменьшаю до размера небольшой надписи без сглаживания. Разумеется, контуры портятся, в них появляются дыры - которые раньше убирались контролем отсечки, но из-за неё же высота букв прыгала.
В общем, выбирайте:
без сглаживания: либо дыры в буквах, либо скачущие буквы
со сглаживанием: красивые буквы с суб-пиксельным позиционированием.


Top
   
PostPosted: Sun Aug 04, 2013 8:19 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Допустим, у тебя есть большой кружок, при высоте 100 пикселей толщина линии кружка 4 пикселей. Конечно, кое-где ширина чуть больше - я создавал в Inkscape.
Attachment:
circle_src.png
circle_src.png [ 406 Bytes | Viewed 2760 times ]

Теперь ты уменьшаешь кружок до высоты в 10 пикселей - в итоге толщина линии равна 0.4 пикселей. Если использовать простое масштабирование без сглаживания (ну да, у нас-то нет сглаживания), то все линии, чья толщина менее 0.5 (а в некоторых реализациях алгоритма - менее 1.0), приравняются к нулю.
Attachment:
circle_nohint_small.png
circle_nohint_small.png [ 155 Bytes | Viewed 2760 times ]

Если покрупнее, то вот:
Attachment:
circle_nohint.png
circle_nohint.png [ 188 Bytes | Viewed 2760 times ]


Теперь я проделал ту же самую операцию уменьшения в ч/б гамме с использованием алгоритма авто-хинтинга с гамма-коррекцией:
Attachment:
circle_hint.png
circle_hint.png [ 202 Bytes | Viewed 2760 times ]


Линии всё еще разрываются - здесь проблема в том, что алгоритм авто-хинтинга плохо работает с окружностями, и намного лучше - с прямыми линиями. В MS же совершенно другие технологии - они встраивают в файл шрифта микрокод, который изменяет форму символа __особенным__ образом. В большинство бесплатно-свободных шрифтов такого микрокода не встроено - предлагаю скачать какой-нибудь левый шрифт, и с отключенным ClearType и сглаживанием попечатать им небольшим кеглем, этак 8м или 10м - будет выглядеть куда хуже, чем "родные". И это при том, что авто-хинтинг все равно будет работать. Такие дела.


Top
   
PostPosted: Sun Aug 04, 2013 8:39 pm 
Offline
Kernel Developer

Joined: Sun Feb 10, 2013 12:37 pm
Posts: 2329
Хорошо - я тебе верю. Меня смутила картинка из Википедии, видимо кто-то не самый умный картинку масштабировал со сглаживанием, хотя как раз для наглядной демонстрации нужно было масштабировать без сглаживания.

Теперь насчет примера с кругом. В свое время когда у меня был БК-0010 с Фокал, то в нем не было функции рисования окружности. Всякие математические функции были. Я изучал алгоритм рисования круга, и сделал его реализацию средствами интерпретатора Фокал, разумеется работало медленно, либо были разрывы в окружности. Далее я начал ломать голову и заметил, что функция отрисовки линий работает довольно шустро и тут в моей голове родился хитрый план. Я начал соединять точки окружности при помощи линий. Причем чтобы минимизировать количество точек, я вроде брал радиус, умножал на Pi и вычислял квадратный корень и еще чего то. Как результат выглядела такая окружность визуально вполне приемлемо, но рисовалась в десятки раз быстрее.

Я вот думаю, а что если добавить в растеризатор принудительную дорисовку линиями между получившимися точками? Чем не аналог хинтинга? Разумеется это так только безумная идея, но вдруг сработает?

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!


Top
   
PostPosted: Sun Aug 04, 2013 9:28 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Mario_r4 wrote:
Я вот думаю, а что если добавить в растеризатор принудительную дорисовку линиями между получившимися точками? Чем не аналог хинтинга? Разумеется это так только безумная идея, но вдруг сработает?

Замкнутые контуры как раз так и рисуются - ограничиваются линиями, а затем заливаются между этими линиями. Вопрос в том, что на маленьких символах расстояние между этими участками линий как раз менее 1 пиксела, а то и меньше. Суть хинтинга в том, что некоторые элементы буквы искусствено утолщаются, а некоторые - отодвигаются, чтобы сохранить визуально "пространство" внутри глифа - то есть, грубо говоря, дырки в буквах типа "а", "я", "б", "ы", "в", "д". :wink:

Прости, если был слишком offensive.


Top
   
PostPosted: Tue Feb 24, 2015 11:40 am 
Offline
User avatar

Joined: Thu Nov 14, 2013 1:25 pm
Posts: 13
viewtopic.php?f=23&t=2771
viewtopic.php?f=26&t=1150&start=75
вот тут еще две темы про шрифты, активненько делают и обсуждают...

_________________
Омская jabber-конференция GNU/Linux:
omsklug@conference.jabber.ru
Сайт Омского LUG:
http://www.omsklug.com


Top
   
PostPosted: Thu Sep 20, 2018 11:19 pm 
Offline

Joined: Thu Sep 20, 2018 10:47 pm
Posts: 14
Хочу поинтересоваться: как освоение шрифтов на настоящий момент?


Top
   
PostPosted: Fri Sep 21, 2018 1:09 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Системное решение viewtopic.php?f=36&t=3084
Внешнее решение вроде вот viewtopic.php?f=4&t=3109


Top
   
PostPosted: Fri Sep 21, 2018 11:46 pm 
Offline

Joined: Thu Sep 20, 2018 10:47 pm
Posts: 14
Да, почитал, немного печально стало, если дело ограничилось моноширинными растровыми шрифтами, хотя ядро GNU/Linux тоже на них сидит.

1) Можно сделать шрифт растровым моновысотным, что повысит качество воспроизведения "П" и "Ш" образных букв, заодно даст небольшую экономию по весу.

2) Хинтинг для растрового шрифта сделать можно, причём как вертикальный, так и горизонтальный.

3) Обсуждение и документирование полезнее до кодинга.

4) Сейчас в Юникоде около 130 К символов, правда некоторые из них дублированы. Но, без этой поддержки будущего вообще-то не будет. Если принять, что средний типографский шрифт имеет высоту по букве "Х" в 3,2 мм, а средний пиксель монитора имеет размер в 0,25 мм, то можно ожидать, что приемлемый шрифт будет иметь размер в 26 точек. При средней матрице в 26х26 точек с глубиной 8 бит получится размер растрового набора примерно в 84 МБ. Если учесть, что в векторных шрифтах на 1 сплайн уходит 6 байт (если не делать всё через double, как в cairo), а на 1 символ уходит около 20 сплайнов, то получается 15 МБ, реально поболее, но с возможностью перестроения под требуемый размер и выводом на печать. Есть ещё подход TeX, он экономит ещё больше места, но имеет свои недостатки.


Top
   
PostPosted: Sat Sep 22, 2018 12:35 am 
Offline
Mentor/Kernel Developer
User avatar

Joined: Thu Mar 26, 2015 5:16 pm
Posts: 1259
Не стоит ожидать многого от интегрированного шрифта. Красивые шрифты всегда отдельно, как и обои, как и прочие свистоперделки.
Solidum wrote:
Если принять, что средний типографский шрифт имеет высоту по букве "Х" в 3,2 мм, а средний пиксель монитора имеет размер в 0,25 мм, то можно ожидать, что приемлемый шрифт будет иметь размер в 26 точек.
Шта? Почему не 13 точек?
Наш системный шрифт 8х16 точек по 1 биту включает более 1400 символов юникода, чего вполне достаточно для письменности слева направо (китайцы и африканцы со своими иероглифами идут лесом), с учётом сжатия занимает в ядре меньше 5Кб.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 33 posts ]  Go to page Previous 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Limited