Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вт июн 27, 2017 11:45 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 26 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Сб авг 03, 2013 1:20 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Вот уже несколько лет продолжается разброд и шатание по теме внедрения и использования новых шрифтов. Было предложено несколько вариантов, начиная от модернизации ф.4 для масштабирования в целое число раз, использование растровых шрифтов на уровне приложений, использование "проволочных" векторных шрифтов на уровне приложений, использование полноценных векторных шрифтов на уровне приложений. Про первый предложенный способ обсуждать особо нечего - мы получаем большие буквы из кубиков и это уровень 60-70 годов прошлого века. Все остальные способы страдают как собственными недостатками, так и одним общим - избыточностью данных, т.е. проблема решается на уровне отдельно взятого приложения, с дублированием RAW областей со шрифтами. Жирно какать хотим товарищи - память она не безразмерная, хотя некоторые придурки по прежнему на "закон" Мура уповают.

Соответственно нужен менеджер шрифтов - я считаю он должен быть реализован на уровне приложения. В нем же должен быть весь код подготавливающий RAW область конкретного запрошенного шрифта. Не важно какой это шрифт в конечном счете все будет в виде картинки с альфа-каналом и служебной областью указателей на конкретный символ и его размеры. Приложению все будет отдаваться через расшаренную память. Также менеджер шрифтов должен отслеживать какой шрифт уже не используется никаким приложением и освобождать память. В общем полный пансион!

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

Итого имеем реализацию поделенную на два уровня:
1) Ядро с кодом отрисовки указанных символов при помощи картинки, указатель на которую предварительно передан.
2) Менеджер шрифтов, у которого текущее приложение будет запрашивать указатель на готовую область с картинками (глифами).

Для того чтобы упростить все процедуры я могу написать код взаимодействия с именованными областями шрифтов в библиотеку proc_lib. Подобно ному как я это сделал для OpenDialog и ColorDialog.

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

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

В любом случае:
art_zh писал(а):

Спойлер: Показать
Да, да! У нас уже есть свои традиции, аксиомы и столпы сообщества! 10 лет все-таки немалый срок.

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


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 10:13 am 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Mario_r4 писал(а):
т.е. проблема решается на уровне отдельно взятого приложения, с дублированием RAW областей со шрифтами. Жирно какать хотим товарищи - память она не безразмерная, хотя некоторые придурки по прежнему на "закон" Мура уповают.

Библиотеки ttf (freetype, tt_stb) вполне могут пользоваться шрифтами из shared memory. Freetype даже включает свой менеджер шрифтов. Для tt_stb таковой менеджер писал я и вроде бы кто-то ещё, но результатов нет.

Mario_r4 писал(а):
Приложению все будет отдаваться через расшаренную память. Также менеджер шрифтов должен отслеживать какой шрифт уже не используется никаким приложением и освобождать память. В общем полный пансион!

Вот это очень хорошо.

Mario_r4 писал(а):
Не важно какой это шрифт в конечном счете все будет в виде картинки с альфа-каналом и служебной областью указателей на конкретный символ и его размеры.

А вот это - иногда не очень. Дело в том, что чтение с экрана - сам знаешь - процедура небыстрая. Вывод картинки с альфа-каналом для множества символов разного размера наверняка приведет к мельтешению как минимум в Qemu на слабых машинах. С другой стороны, вывод текста с настоящим альфа-каналом нужен в единицах случаев: в трехмерной графике (где всё равно применять к тексту преобразования), в играх и при размещении текстов поверх фотографий. Во всех остальных случаях текст выводится поверх какого-то одного цвета, соответственно, можно подготовить область этого цвета, и сделать слияние RAW-данных символа ("глифа") с этим фоном, а затем быстро вывести.
Следует отметить, что часто требуемый цвет шрифта отличается от черного - в этом случае RAW-данные глифа используются как маска смешения желаемого цвета и фона (будь то картинка с экрана или просто равномерно закрашенная область).

Mario_r4 писал(а):
В ядре будет таблица с указателями на примонтированные расшаренные области с данными шрифтов (примонтированные к текущему приложению естественно, а не к ядру) и установив указатель на выбранный шрифт, мы просто используем его со всем функционалом ф.4. Для ворчунов - синтаксис ф.4 совсем не поменяется, если не считать добавление обработки случая использования шрифта N3. Для совсем уже ворчунов можно запилить новую системную функцию для вывода, но мне кажется это излишне.

Почему бы просто не передавать указатель на шрифт? А что насчет расчета размеров выводимой надписи? Этим будет заниматься библиотека?
Иногда требуется знать размер выведенной надписи уже после её вывода, при этом, очевидно, сама функция вывода этот размер знает - она как-нибудь будет его возвращать? Мне кажется, что новая функция (в этом же менеджере шрифтов, коли он используется, или же системная) - более логичное решение, чем раздувание ф. 4. Дополнительно, использование менеджера шрифтов может позволить использовать сразу несколько типов шрифтов - растровые и векторные, например.

Вот такие вопросы у меня возникли. Mario, респект тебе и уважуха. С кодом растеризации - базара нет, хочешь - дам ассемблерный листинг, хочешь - COFF-библиотечку (которую можно слинковать с fasm-бинарником или другой coff-библиотечкой).


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 5:40 pm 
Не в сети
KSoC/GSoC Student

Зарегистрирован: Ср июл 11, 2012 3:17 am
Сообщения: 224
А кто-то рассматривал CHR - Формат файлов штриховых шрифтов Borland. Или это не актуально?
Цитата:
Приемущества данного шрифта налицо: минимальная потеря качества шрифта при его увеличении; малый размер; легкость создания оригинальных надписей (его можно "пустить" по определенной траектории); короче, вектор он и в Африке вектор.

весят они от 4 kb до 9 kb, максимум что встречал 15 kb.
вот описание формата: http://zxdn.narod.ru/coding/fu1vechr.htm
ИзображениеИзображение
шрифт при большом увеличении.

PS: полнофункциональные ttf очень жирные по размеру, зато - полная совместимость с другими ос.
PPS: брать сами chr смысла нет, но использовать подобный подход и схожую структуру ни кто не запрещает.
PPPS: мое мнение очень субъективно и не претендует на какую либо профессиональную точку зрения по этому вопросу. Подкупает компактность и функционал.)))


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 6:02 pm 
Не в сети

Зарегистрирован: Вт июл 26, 2011 11:03 pm
Сообщения: 62
Цитата:
е ввести еще одну функцию, которая устанавливает третий используемый шрифт для текущего приложения
Хорошая идея со шрифтом номер 3 и функцией под него.


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 7:28 pm 
Не в сети

Зарегистрирован: Ср май 18, 2005 7:27 pm
Сообщения: 1001
Akyltist писал(а):
А кто-то рассматривал CHR - Формат файлов штриховых шрифтов Borland. Или это не актуально?


Было реализовано willow на уровне приложения, дальше этого почему-то не пошло.
viewtopic.php?f=5&t=1602&p=41454&hilit=CHR#p41433

см. исходники предыдущих дистров (в колибри 0.5.8.1 лежат в
k0581src/programs/Willow/bgi_fonts )


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:16 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Шрифты BGI выглядят отвратно на больших размерах, это реально прошлый век, ребята. Растровые шрифты, заточенные под определенные размеры - хорошо, ttf - очень хорошо, svg - замечательно.


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:24 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SoUrcerer писал(а):
А вот это - иногда не очень. Дело в том, что чтение с экрана - сам знаешь - процедура небыстрая. Вывод картинки с альфа-каналом для...

Я уже в чате говорил тебе пару месяцев назад, что можно выводить неполноценный альфа-канал (на уровне 1/0 - есть пиксел, нет пиксела), совсем без чтения области видеопамяти - только запись в нее. Минус в том, что сглаженные шрифты так не выведешь.
SoUrcerer писал(а):
Почему бы просто не передавать указатель на шрифт? А что насчет расчета размеров выводимой надписи? Этим будет заниматься библиотека? Иногда требуется знать размер выведенной надписи уже после её вывода, при этом, очевидно, сама функция вывода этот размер знает - она как-нибудь будет его возвращать? Мне кажется, что новая функция (в этом же менеджере шрифтов, коли он используется, или же системная) - более логичное решение, чем раздувание ф. 4.

В случае дальнейшего использования ф.4 передавать указатель невозможно - все регистры уже так или иначе заняты. Если делать вывод новой функцией, то придется кучу кода переписывать именно на нее. При использовании ф.4 требуются минимальные доработки. Это естественно при использовании моноширинных шрифтов. Если потребуется вычислить размер шрифта, но можно добавить в функцию (устанавливающую шрифт), подфункцию вычисляющую размер строки. Как я уже говорил передавать в библиотеку указатели на другую библиотеку дюже неудобно в использовании, так что лучше пусть код вычисляющий размер строки пропишется в ядре. Это меньшее из зол.
SoUrcerer писал(а):
С кодом растеризации - базара нет, хочешь - дам ассемблерный листинг, хочешь - COFF-библиотечку (которую можно слинковать с fasm-бинарником или другой coff-библиотечкой).

Я пока на кошках растровых шрифтах потренируюсь. В любом случае реализация займет значительное время.

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


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:28 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Wildwest писал(а):
Akyltist писал(а):
А кто-то рассматривал CHR - Формат файлов штриховых шрифтов Borland. Или это не актуально?


Было реализовано willow на уровне приложения, дальше этого почему-то не пошло.
viewtopic.php?f=5&t=1602&p=41454&hilit=CHR#p41433

см. исходники предыдущих дистров (в колибри 0.5.8.1 лежат в
k0581src/programs/Willow/bgi_fonts )

Смею заметить, что RTFREAD и используемый им CHR шрифт остались. Я убрал, то что занимало место и по факту не приносило преимуществ. С SVN никто код не удалял и если кому то потребуется, то всегда может взять и сделать для себя.

Однако я согласен с SoUrcerer - такие шрифты это не вариант, к тому же отрисовка реализована по точечно, а это очень медленно.

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


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:30 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SoUrcerer писал(а):
svg - замечательно.

Ловлю на слове! Будешь еще и растеризатор SVG лепить. :wink:

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


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:30 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.
Функция 4 может же и произвольной ширины символы выводить, разве нет?
Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:43 pm 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SoUrcerer писал(а):
Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.

Можно для растровых упрощенный альфа-канал, а для векторных уже думать. Почему кстати не выведешь? Просто они будут грубые, без сглаживания.
SoUrcerer писал(а):
Функция 4 может же и произвольной ширины символы выводить, разве нет?

Может, но без знания длины строки сам понимаешь даже со вторым системным шрифтом приходится кувыркаться в стиле BDSM с кодом. :-)
SoUrcerer писал(а):
Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.

Я помню, ты мне даже скидывал код. Однако это не завершенная вещь и даже не оформлено в отдельную вменяемую библиотеку вроде - чтобы легко и быстро, как например плагины от zSea. :)

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


Вернуться к началу
СообщениеДобавлено: Сб авг 03, 2013 11:57 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Вложение:
no_hint.png
no_hint.png [ 6.88 КБ | 2183 просмотра ]

Растеризация через freetype2 без хинтинга - слева со сглаживанием, справа без него.
С хинтингом, конечно, получше - но STB_TTF не поддерживает его. Добиться хорошего качества картинки без хинтинга можно только при субпиксельном позиционировании и сглаживании по вертикали.


Вернуться к началу
СообщениеДобавлено: Вс авг 04, 2013 1:11 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
Во втором случае растеризация какая то кривая - почему буквы разные по высоте? Так не должно быть.

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


Вернуться к началу
СообщениеДобавлено: Вс авг 04, 2013 8:29 am 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Напротив, так все и есть, когда нет хинтинга и сгладиввеия.


Вернуться к началу
СообщениеДобавлено: Вс авг 04, 2013 11:27 am 
Не в сети
Kernel Developer

Зарегистрирован: Вс фев 10, 2013 12:37 pm
Сообщения: 2329
SoUrcerer писал(а):
Напротив, так все и есть, когда нет хинтинга и сгладиввеия.

По правилам каллиграфии, да и здравого смысла, буквы одного порядка (строчные к строчным, заглавные к заглавным) должны писаться с одной высотой. Какое отношение к этому имеет сглаживание? Тут явно ошибка в реализации вывода, потому что отдельные буквы одной высоты, а другие отличаются. Например, строчная С одной высоты с Ё, но В вдруг и ВНЕЗАПНО меньше - это нелогично!

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 26 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB