Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Dec 07, 2019 10:40 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 118 posts ]  Go to page Previous 14 5 6 7 8 Next
Author Message
PostPosted: Fri Aug 05, 2011 4:50 pm 
art_zh wrote:
Системные фонты 0 и 1 никто отменять не собирается, но почему бы не ввести подгружаемые шрифты №3, 4, ... и не переделать для начала только один Tinypad под сменный шрифт?

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


Top
   
PostPosted: Fri Aug 05, 2011 7:04 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
art_zh wrote:
Ух ты, как все оживились-то :)
Foldl wrote:
А зачем? Sorcerer уже имеет алгоритм растеризации векторных шрифтов,

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

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


Top
   
PostPosted: Fri Aug 05, 2011 7:44 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
Sourcerer
Буква "б" - это 2 глифа. Верхняя закорючка - 6 пикселей (4 байта), колечко - еще 15 (8 байт). Но это колечко - общий глиф для 7 или 8 символов, так что суди сам о плотности упаковки...


Top
   
PostPosted: Fri Aug 05, 2011 8:06 pm 
Offline

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

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


Top
   
PostPosted: Fri Aug 05, 2011 9:23 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
Sorcerer wrote:
Увы, это только для части пиксельных шрифтов так.В реальности каждая буква иногда очень сильно отличается от своих родственников. ... кстати,к вопросу о букве б.Предлагаю тем же tahoma размера 16-20 (это гораздо меньше 63 пкс в высоту) набрать рядом буквы б и о. Разницу видно невооруженным глазом.
Да, согласен. В разных шрифтах - разные "родственники". Я сейчас вожусь с Курьером 9х16, там двойников больше и буквы тонкие - как раз то что надо. Размер 31х63 конечно абсурдно большой, я просто забил 6 бит на Y и 5 бит на Х, чтоб на все случаи жизни хватило. Мало ли что, может кто захочет себе крупный фонт 36х20 забабахать? Хотя на больших глифах конечно у безье-шрифтов будет преимущество в размере (но не в скорости отрисовки).
Sorcerer wrote:
Насчет скорости-хочу непредвзятый тест производительности.И еще проблема-кто шрифты рисовать-то будет?Тяжелое и неблагодарное занятие.
Будет шрифт - будет и тест (MGB устроит в качестве непредвзятого теста?) .
Работка действительно муторная (я пока только до цифры 3 дошел), но чем дальше в лес- тем чаще партизаны - тем больше общих линий.


Top
   
PostPosted: Fri Aug 05, 2011 9:45 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Наверное;) катит только твой вариант только для тонких шрифтов, а это не годится для шрифтов в браузерах, продвинутых редакторах. А вместо старых системных-идея хорошая. Вместо запатентованного шрифта может лучше использовать что-то свободное и похожее?


Top
   
PostPosted: Fri Aug 05, 2011 9:55 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
Сейчас хотя бы что-нибудь читаемое, а то глаза совсем сели.
А потом - посмотрим на результаты.


Top
   
PostPosted: Sat Aug 06, 2011 12:59 am 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
art_zh wrote:
Есть задумка сделать системные шрифты векторными, но НЕмасштабируемыми.


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


Top
   
PostPosted: Sat Aug 06, 2011 12:51 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
johnfound
Масштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.

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

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


Top
   
PostPosted: Sat Aug 06, 2011 1:28 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
art_zh wrote:
johnfoundМасштабировать (х2, х3) конечно можно, но получится коряво - также как Zoom для маленьких растровых шрифтов.


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


Top
   
PostPosted: Sat Aug 06, 2011 2:53 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Думаю,что на небольших размерах можно шрифты с помощью моего алгоритма делать,хотя и выйдет не так компактно,как вручную


Top
   
PostPosted: Sat Aug 06, 2011 4:13 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
Ну не годятся все эти безье и сплайны для маленьких букв. Для больших - да, нужно.
А 10-пиксельная линия всегда будет выглядеть коряво, даже с антиалайасингом.
Поэтому в комплекте к любому приличному шрифту всегда поставляются несколько его экранных версий в разных типоразмерах.
Допиленных вручную.
Wiki wrote:
One issue is that fonts do not actually scale linearly at small sizes; features of the glyphs will become proportionally too large or small and they start to look wrong. PostScript avoided this problem with the inclusion of hints which could be saved along with the font outlines. Basically they are additional information in horizontal or vertical bands that help identify the features in each letter that are important for the rasterizer to maintain. The result was significantly better-looking fonts even at low resolution; it had formerly been believed that hand-tuned bitmap fonts were required for this task

http://en.wikipedia.org/wiki/PostScript


Last edited by art_zh on Sat Aug 06, 2011 11:53 pm, edited 1 time in total.

Top
   
PostPosted: Sat Aug 06, 2011 4:49 pm 
Offline

Joined: Fri Feb 18, 2011 3:13 pm
Posts: 201
art_zh wrote:
Ну не годятся все эти безье и сплайны для маленьких букв. Для больших - да, нужно....
...Допиленных вручную.


Что верно - то верно. Ручно нарисованные шрифты всегда лучше.


Top
   
PostPosted: Sat Aug 06, 2011 8:32 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 796
turtle-графика открывает возможности для сколь-угодно глубокой детализации не только шрифтов... но и элементов интерфейса


Top
   
PostPosted: Sun Aug 07, 2011 1:49 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1358
XVilka
Одних turtle-линий для GUI недостаточно.

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

Т.е. нужен полноценный метаязык, и [ядерный] парсер к нему.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 118 posts ]  Go to page Previous 14 5 6 7 8 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited