Запустить не удалось, ни под эмулятором, ни под виртуальной машиной.Albom wrote:вот мой вариант библиотеки для работы со шрифтами.
работает с растровыми шрифтами формата psf.
рекомендуется при использовании библиотеки gb_lib.
Масштабируемые шрифты
Из исходников библиотеки я понял, что:
1)в /sys/lib/ нужно поместить gblib.obj(я нашёл на FTP) и psf_font.obj
2)в /sys/fonts/ пестить cp866-8x16.psf (этот шрифт задан в исходнике примера). Соответственно для загрузки других шрифтов нужно менять название файла шрифта в исходнике и перекомпилировать программу.
Судя по исходникам формат шрифта простой, поэтому нет смысла писать декодер на C. Лучше писать на ассемблере. Будет и быстрее работать и компактнее будет код.
1)в /sys/lib/ нужно поместить gblib.obj(я нашёл на FTP) и psf_font.obj
2)в /sys/fonts/ пестить cp866-8x16.psf (этот шрифт задан в исходнике примера). Соответственно для загрузки других шрифтов нужно менять название файла шрифта в исходнике и перекомпилировать программу.
Судя по исходникам формат шрифта простой, поэтому нет смысла писать декодер на C. Лучше писать на ассемблере. Будет и быстрее работать и компактнее будет код.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
всё правильно. мне надо было написать хоть какую-то документацию, но не было времени - готовился к экзамену.andrew_programmer wrote:Из исходников библиотеки я понял, что
Скорее всего, что перепишу сам. Хотя от посторонней помощи не отказался бы. Формат файла - простейший. Сначала идёт заголовок - 2 магических числа, потом режим (пока не разобрался что означает) и высота символа. После заголовка идут битмапы (1 бит на пиксель) символов. Т.е. если высота симовола 16 - то на символ идёт 16 байт, если 14 - то 14 байт. В принципе, есть системная ф-ция, позволяющая выводить изображения с палитрой, но я использую свою библиотеку (gb_lib) потому, что она работает быстрее (все операции производятся с буфером, а не экраном) и там есть функция для копирования изображений с прозрачным цветом.andrew_programmer wrote: Судя по исходникам формат шрифта простой, поэтому нет смысла писать декодер на C. Лучше писать на ассемблере. Будет и быстрее работать и компактнее будет код.
http://fonts.ru/public/
Кому-то не хватало шрифтов с открытой лицензией, вот, они уже есть
Кому-то не хватало шрифтов с открытой лицензией, вот, они уже есть
Написал простенький просмотрщик шрифтов PSF.
- Attachments
-
-
screens.zip (32.19 KiB)Downloaded 396 times
-
psfview-0.1.zip (27.71 KiB)Downloaded 388 times
-
Есть задумка сделать системные шрифты векторными, но НЕмасштабируемыми.
Концепция такая:
1) символ - это набор линий в поле размером не более 31х63 пикселей.
2) линия - это связная цепочка пикселей, вдоль которой осуществляется рисование
Кодирование цепочки - трехбитовыми полями:- 2а) Конец рисования линии кодируется возвратом в предпоследнюю точку (NB: сумма двух любых противоположных направлений дает 7).
3) одинаковые (с точностью до сдвига по X и Y) линии могут быть общими у одного или нескольких разных символов
4) некоторые специальные символы (пробел, отдельная точка, псевдографика с кодами #176, #177 и др.), не попадающие в общую классификацию (см.1-3), требуют специальных (вариант: растровых) методов отображения.
Линия всегда связна, может пересекать саму себя (точка пересечения при этом будет отрисована дважды ), но не может разворачиваться назад (см. 2а)
Ожидается значительное ускорение вывода текста по сравнению как с растровыми, так и с масштабируемыми векторными шрифтами. То, что шрифты при этом получатся гораздо более компактными - очевидно.
Концепция такая:
1) символ - это набор линий в поле размером не более 31х63 пикселей.
2) линия - это связная цепочка пикселей, вдоль которой осуществляется рисование
Кодирование цепочки - трехбитовыми полями:
Code: Select all
6 5 4
7 • 0
3 2 1
3) одинаковые (с точностью до сдвига по X и Y) линии могут быть общими у одного или нескольких разных символов
Code: Select all
примеры:
- = (вертикальный сдвиг)
b d p q (сдвиг вертикальной линии относительно кольца - всего две линии определяют 6 разных символов)
Линия всегда связна, может пересекать саму себя (точка пересечения при этом будет отрисована дважды ), но не может разворачиваться назад (см. 2а)
Ожидается значительное ускорение вывода текста по сравнению как с растровыми, так и с масштабируемыми векторными шрифтами. То, что шрифты при этом получатся гораздо более компактными - очевидно.
art_zh
А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов, вопрос в другом, кто добавит поддержку масштабируемых шрифтов в Tinipad, например?
Про ускорение вывода не совсем очевидно. Если растр генерировать только однажды, а потом выводить только его, то разницы в скорости почти не будет. При ином алгоритме может быть, но сильно зависит от ситуации, мне кажется.
А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов, вопрос в другом, кто добавит поддержку масштабируемых шрифтов в Tinipad, например?
Про ускорение вывода не совсем очевидно. Если растр генерировать только однажды, а потом выводить только его, то разницы в скорости почти не будет. При ином алгоритме может быть, но сильно зависит от ситуации, мне кажется.
Не понимаю, за счет чего будет ускорение вывода текста? Не уверен, что шрифты выйдут более компактными, чем растровые.art_zh wrote:Есть задумка сделать системные шрифты векторными, но НЕмасштабируемыми.
Ожидается значительное ускорение вывода текста по сравнению как с растровыми, так и с масштабируемыми векторными шрифтами. То, что шрифты при этом получатся гораздо более компактными - очевидно.
Алгоритм - одно, реализация - другое. Даже если алгоритм простой, не использует дробных чисел, и операций деления всего пару. У меня есть наработки библиотеки на Си, а добрый Asper переводит все это на кошерный ассемблер, хотя дел у него (наверняка) очень много. Всем, конечно, хочется поскорее Сделать поддержку библиотеки в программах можно очень и очень просто: к примеру, в файле "fonts.ini" хранится информация о системном шрифте по умолчанию, а в библиотеке сделать аналог 4й системной функции, и вызывать ее из кода программ вместо int 0x40.Foldl wrote:art_zh
А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов, вопрос в другом, кто добавит поддержку масштабируемых шрифтов в Tinipad, например?
art_zh
Ты уж извини, но фигня какая-то. Напоминает ту картинку где из буханки хлеба сделали троллейбус.
Если уж делать векторные, то полностью векторные. В противном случае растровые замечательно в PNG упаковываются, а распаковщиков у нас как минимум две реализации уже есть.
Ты уж извини, но фигня какая-то. Напоминает ту картинку где из буханки хлеба сделали троллейбус.
Если уж делать векторные, то полностью векторные. В противном случае растровые замечательно в PNG упаковываются, а распаковщиков у нас как минимум две реализации уже есть.
Если бы такое было возможно, то сделали бы иначе -- заменяли бы системный шрифт на тот, который нравится (например, значительно крупнее). Но если программы расчитывают, что буквы системой выводятся всегда определенного размера (4 пиксела, да?), то всё попадает.Sorcerer wrote:Сделать поддержку библиотеки в программах можно очень и очень просто: к примеру, в файле "fonts.ini" хранится информация о системном шрифте по умолчанию, а в библиотеке сделать аналог 4й системной функции, и вызывать ее из кода программ вместо int 0x40.
Если я ошибаюсь, то как мне увеличить размер шрифта?
Ух ты, как все оживились-то
Мне надо.
А скольно реальных пикселей в символе? В среднем - 15-20...
Но не обязательно сразу и во всех программах. Системные фонты 0 и 1 никто отменять не собирается, но почему бы не ввести подгружаемые шрифты №3, 4, ... и не переделать для начала только один Tinypad под сменный шрифт?
Здесь фишка в другом: рисовать векторные шрифты не в растровой, а в векторной форме: "пиксель вверх, потом вниз и вправо, еще вправо, стоп".Foldl wrote:А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов,
Кому надо, тот и добавит.Foldl wrote:вопрос в другом, кто добавит поддержкумасштабируемыхшрифтов в Tinipad, например?
Мне надо.
При выводе растра в каждом символе 8x16 (включая пробел!) рисуются 128 пикселей. Правда, в битмапе они выводятся группами по 4 пикселя, но это незначительное ускорение.Foldl wrote:Про ускорение вывода не совсем очевидно. Если растр генерировать только однажды, а потом выводить только его, то разницы в скорости почти не будет. При ином алгоритме может быть, но сильно зависит от ситуации, мне кажется.
А скольно реальных пикселей в символе? В среднем - 15-20...
Не ошибаешься - надо править код.Foldl wrote:Если бы такое было возможно, то сделали бы иначе -- заменяли бы системный шрифт на тот, который нравится (например, значительно крупнее). Но если программы расчитывают, что буквы системой выводятся всегда определенного размера (4 пиксела, да?), то всё попадает.
Если я ошибаюсь, то как мне увеличить размер шрифта?
Но не обязательно сразу и во всех программах. Системные фонты 0 и 1 никто отменять не собирается, но почему бы не ввести подгружаемые шрифты №3, 4, ... и не переделать для начала только один Tinypad под сменный шрифт?
Вот это здравая идея. Я в свое время ее тоже обдумывал, но на фоне целых трех программистов взявшихся за реализацию шрифтов (как у нас принято бросать на полдороге), вежливо промолчал, раз более умные и опытные люди взялись делать. А так достаточно лишь реализации одного подгружаемого шрифта на одно приложение (чтобы в процессе переключения задач шрифт внезапно не был изменен другим приложением), чтобы такой вот динамической подгрузкой выводить энное количество шрифтов. Причем приложение само будет знать какой шрифт загрузило для себя (вернее это будет знать программист). Чтобы не иметь проблем с дисковыми устройствами подгружаемые шрифты держатся в памяти (на самом деле не так уж и они много занимают памяти) и акробатически ловко подменяются по мере вывода текста.art_zh wrote:Системные фонты 0 и 1 никто отменять не собирается, но почему бы не ввести подгружаемые шрифты №3, 4, ... и не переделать для начала только один Tinypad под сменный шрифт?
Ну и ну. Глиф для буквы "б" в размере 8x16. Тут куча кривых Безье, если делить на отрезки, то не менее 10 отрезков. Какая разница, рисовать 10 отрезков (или даже всего 20 точек) по координатам из таблицы, или 128 точек группами по 4?art_zh wrote:Ух ты, как все оживились-тоЗдесь фишка в другом: рисовать векторные шрифты не в растровой, а в векторной форме: "пиксель вверх, потом вниз и вправо, еще вправо, стоп".Foldl wrote:А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов,Кому надо, тот и добавит.Foldl wrote:вопрос в другом, кто добавит поддержкумасштабируемыхшрифтов в Tinipad, например?
Мне надо.При выводе растра в каждом символе 8x16 (включая пробел!) рисуются 128 пикселей. Правда, в битмапе они выводятся группами по 4 пикселя, но это незначительное ускорение.Foldl wrote:Про ускорение вывода не совсем очевидно. Если растр генерировать только однажды, а потом выводить только его, то разницы в скорости почти не будет. При ином алгоритме может быть, но сильно зависит от ситуации, мне кажется.
А скольно реальных пикселей в символе? В среднем - 15-20...
А если 31х63 - так это вообще безумие, толщина линий в глифах как задаваться будет? Или шрифт будет неэстетично выглядеть, или выигрыша в скорости не будет, мне кажется.
Sourcerer
Буква "б" - это 2 глифа. Верхняя закорючка - 6 пикселей (4 байта), колечко - еще 15 (8 байт). Но это колечко - общий глиф для 7 или 8 символов, так что суди сам о плотности упаковки...
Буква "б" - это 2 глифа. Верхняя закорючка - 6 пикселей (4 байта), колечко - еще 15 (8 байт). Но это колечко - общий глиф для 7 или 8 символов, так что суди сам о плотности упаковки...
Увы, это только для части пиксельных шрифтов так.В реальности каждая буква иногда очень сильно отличается от своих родственников. Насчет скорости-хочу непредвзятый тест производительности.И еще проблема-кто шрифты рисовать-то будет?Тяжелое и неблагодарное занятие.
Совершенно не против затеи, но высказываю опасения.
кстати,к вопросу о букве б.Предлагаю тем же tahoma размера 16-20 (это гораздо меньше 63 пкс в высоту) набрать рядом буквы б и о. Разницу видно невооруженным глазом.
Совершенно не против затеи, но высказываю опасения.
кстати,к вопросу о букве б.Предлагаю тем же tahoma размера 16-20 (это гораздо меньше 63 пкс в высоту) набрать рядом буквы б и о. Разницу видно невооруженным глазом.
Who is online
Users browsing this forum: No registered users and 6 guests