Окончательное решение вопроса со шрифтами

Kernel architecture questions
  • 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
    ImageImage
    шрифт при большом увеличении.

    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-библиотечкой).
    Я пока на кошках растровых шрифтах потренируюсь. В любом случае реализация займет значительное время.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • 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 - такие шрифты это не вариант, к тому же отрисовка реализована по точечно, а это очень медленно.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • SoUrcerer wrote:svg - замечательно.
    Ловлю на слове! Будешь еще и растеризатор SVG лепить. :wink:
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.
    Функция 4 может же и произвольной ширины символы выводить, разве нет?
    Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.
  • SoUrcerer wrote:Неполноценный альфа-канал подходит только для растровых шрифтов. Векторные так не выведешь - про ttf то есть можно забыть.
    Можно для растровых упрощенный альфа-канал, а для векторных уже думать. Почему кстати не выведешь? Просто они будут грубые, без сглаживания.
    SoUrcerer wrote:Функция 4 может же и произвольной ширины символы выводить, разве нет?
    Может, но без знания длины строки сам понимаешь даже со вторым системным шрифтом приходится кувыркаться в стиле BDSM с кодом. :-)
    SoUrcerer wrote:Растеризатор для SVG-шрифтов, если ты не помнишь, я писал.
    Я помню, ты мне даже скидывал код. Однако это не завершенная вещь и даже не оформлено в отдельную вменяемую библиотеку вроде - чтобы легко и быстро, как например плагины от zSea. :)
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • no_hint.png
    no_hint.png (6.88 KiB)
    Viewed 11090 times
    Растеризация через freetype2 без хинтинга - слева со сглаживанием, справа без него.
    С хинтингом, конечно, получше - но STB_TTF не поддерживает его. Добиться хорошего качества картинки без хинтинга можно только при субпиксельном позиционировании и сглаживании по вертикали.
  • Во втором случае растеризация какая то кривая - почему буквы разные по высоте? Так не должно быть.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Напротив, так все и есть, когда нет хинтинга и сгладиввеия.
  • SoUrcerer wrote:Напротив, так все и есть, когда нет хинтинга и сгладиввеия.
    По правилам каллиграфии, да и здравого смысла, буквы одного порядка (строчные к строчным, заглавные к заглавным) должны писаться с одной высотой. Какое отношение к этому имеет сглаживание? Тут явно ошибка в реализации вывода, потому что отдельные буквы одной высоты, а другие отличаются. Например, строчная С одной высоты с Ё, но В вдруг и ВНЕЗАПНО меньше - это нелогично!
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 4 guests