Board.KolibriOS.org

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

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

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

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

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

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

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

В любом случае:

art_zh wrote:Проблема действительно назрела. Буковки отпугивают клиентов...

Spoiler:

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

Mario_r4 wrote:т.е. проблема решается на уровне отдельно взятого приложения, с дублированием RAW областей со шрифтами. Жирно какать хотим товарищи - память она не безразмерная, хотя некоторые придурки по прежнему на "закон" Мура уповают.

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

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

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

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

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

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

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

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

А кто-то рассматривал CHR - Формат файлов штриховых шрифтов Borland. Или это не актуально?

Приемущества данного шрифта налицо: минимальная потеря качества шрифта при его увеличении; малый размер; легкость создания оригинальных надписей (его можно "пустить" по определенной траектории); короче, вектор он и в Африке вектор.

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

шрифт при большом увеличении.

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

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

Хорошая идея со шрифтом номер 3 и функцией под него.

Akyltist wrote:А кто-то рассматривал CHR - Формат файлов штриховых шрифтов Borland. Или это не актуально?

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

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

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

SoUrcerer wrote:А вот это - иногда не очень. Дело в том, что чтение с экрана - сам знаешь - процедура небыстрая. Вывод картинки с альфа-каналом для...

Я уже в чате говорил тебе пару месяцев назад, что можно выводить неполноценный альфа-канал (на уровне 1/0 - есть пиксел, нет пиксела), совсем без чтения области видеопамяти - только запись в нее. Минус в том, что сглаженные шрифты так не выведешь.

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

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

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

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

Wildwest wrote:

Akyltist wrote:А кто-то рассматривал 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 - такие шрифты это не вариант, к тому же отрисовка реализована по точечно, а это очень медленно.

SoUrcerer wrote:svg - замечательно.

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

Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.
Функция 4 может же и произвольной ширины символы выводить, разве нет?
Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.

SoUrcerer wrote:Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.

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

SoUrcerer wrote:Функция 4 может же и произвольной ширины символы выводить, разве нет?

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

SoUrcerer wrote:Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.

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

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

Во втором случае растеризация какая то кривая - почему буквы разные по высоте? Так не должно быть.

Напротив, так все и есть, когда нет хинтинга и сгладиввеия.

SoUrcerer wrote:Напротив, так все и есть, когда нет хинтинга и сгладиввеия.

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