Board.KolibriOS.org

art_zh
А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов, вопрос в другом, кто добавит поддержку масштабируемых шрифтов в Tinipad, например?
Про ускорение вывода не совсем очевидно. Если растр генерировать только однажды, а потом выводить только его, то разницы в скорости почти не будет. При ином алгоритме может быть, но сильно зависит от ситуации, мне кажется.

Не понимаю, за счет чего будет ускорение вывода текста? Не уверен, что шрифты выйдут более компактными, чем растровые.


Алгоритм - одно, реализация - другое. Даже если алгоритм простой, не использует дробных чисел, и операций деления всего пару. У меня есть наработки библиотеки на Си, а добрый Asper переводит все это на кошерный ассемблер, хотя дел у него (наверняка) очень много. Всем, конечно, хочется поскорее Сделать поддержку библиотеки в программах можно очень и очень просто: к примеру, в файле "fonts.ini" хранится информация о системном шрифте по умолчанию, а в библиотеке сделать аналог 4й системной функции, и вызывать ее из кода программ вместо int 0x40.

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

Если бы такое было возможно, то сделали бы иначе -- заменяли бы системный шрифт на тот, который нравится (например, значительно крупнее). Но если программы расчитывают, что буквы системой выводятся всегда определенного размера (4 пиксела, да?), то всё попадает.

Если я ошибаюсь, то как мне увеличить размер шрифта?

Ух ты, как все оживились-то

Здесь фишка в другом: рисовать векторные шрифты не в растровой, а в векторной форме: "пиксель вверх, потом вниз и вправо, еще вправо, стоп".
Кому надо, тот и добавит.
Мне надо.
При выводе растра в каждом символе 8x16 (включая пробел!) рисуются 128 пикселей. Правда, в битмапе они выводятся группами по 4 пикселя, но это незначительное ускорение.
А скольно реальных пикселей в символе? В среднем - 15-20...

Не ошибаешься - надо править код.
Но не обязательно сразу и во всех программах. Системные фонты 0 и 1 никто отменять не собирается, но почему бы не ввести подгружаемые шрифты №3, 4, ... и не переделать для начала только один Tinypad под сменный шрифт?

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

Ну и ну. Глиф для буквы "б" в размере 8x16. Тут куча кривых Безье, если делить на отрезки, то не менее 10 отрезков. Какая разница, рисовать 10 отрезков (или даже всего 20 точек) по координатам из таблицы, или 128 точек группами по 4?
А если 31х63 - так это вообще безумие, толщина линий в глифах как задаваться будет? Или шрифт будет неэстетично выглядеть, или выигрыша в скорости не будет, мне кажется.

Sourcerer
Буква "б" - это 2 глифа. Верхняя закорючка - 6 пикселей (4 байта), колечко - еще 15 (8 байт). Но это колечко - общий глиф для 7 или 8 символов, так что суди сам о плотности упаковки...

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

кстати,к вопросу о букве б.Предлагаю тем же tahoma размера 16-20 (это гораздо меньше 63 пкс в высоту) набрать рядом буквы б и о. Разницу видно невооруженным глазом.

Да, согласен. В разных шрифтах - разные "родственники". Я сейчас вожусь с Курьером 9х16, там двойников больше и буквы тонкие - как раз то что надо. Размер 31х63 конечно абсурдно большой, я просто забил 6 бит на Y и 5 бит на Х, чтоб на все случаи жизни хватило. Мало ли что, может кто захочет себе крупный фонт 36х20 забабахать? Хотя на больших глифах конечно у безье-шрифтов будет преимущество в размере (но не в скорости отрисовки).
Будет шрифт - будет и тест (MGB устроит в качестве непредвзятого теста?) .
Работка действительно муторная (я пока только до цифры 3 дошел), но чем дальше в лес- тем чаще партизаны - тем больше общих линий.

Наверное;) катит только твой вариант только для тонких шрифтов, а это не годится для шрифтов в браузерах, продвинутых редакторах. А вместо старых системных-идея хорошая. Вместо запатентованного шрифта может лучше использовать что-то свободное и похожее?

Сейчас хотя бы что-нибудь читаемое, а то глаза совсем сели.
А потом - посмотрим на результаты.

Идея не новая - в Apple II так кодировались спрайты чтобы быстро рисовать из Бейсика. Только назывались не спрайты, а как то по-другому (память уже не та...)
Разумно сделать кодировка 4-х битная. 3 бита на направление и 1 на действие - перемещение/рисование.
Кстати, эти изображения по существу векторные и их можно мащабировать.

johnfound
Масштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.

Конечно идея стара как мир. Я помню более древние времена: в Turbo Pascal 3.0 была библиотека черепашьей графики, где трак тоже запоминался 4-битовыми цепочками.
И даже еще более древние: именно такой принцип кодировки был зашит в ROM (матрица с тысячами вручную впаяных диодов!) чуда советской электроники - векторно-растрового дисплея РИН-609.

Только всё-таки 3 битная кодировка линий на 25% короче. И даже такая упаковка оказывается избыточной: для плавных линий (без острых углов) можно обойтись и двумя битами на пиксель.

Кодировка не все. Альгоритм рисования все. Ничего не мешает масштабировать х1.5 или х21.333 например.
Но в конце концов, лучше иметь полностью масштабируемые шрифты. Работа Sourcerer-а выглядела вполне перспективная. Жаль, человек на ассемблере не пишет и дело затягивается.