Board.KolibriOS.org

Official KolibriOS board
It is currently Sun Jun 16, 2019 6:46 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 61 posts ]  Go to page 1 2 3 4 5 Next
Author Message
PostPosted: Sat Nov 26, 2011 2:48 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
Задумка зародилась здесь, но в том сабже была оффтопиком.

По ходу реализации конкретный формат новых шрифтов и код парсера много раз менялась: код цепочки из 3-битного ужался до 2бит на угол, максимальный размел символа - до 12х21, введены стандартные реперные точки и обработка симметричных линий, и т.п.

Но основные идеи во многом остаются прежними:

1) шрифты состоят из символов (chars), символы - из штрихов (ticks); отдельные штрихи могут быть общими для разных символов и даже шрифтов.

2) шрифты кодируются 256-элементными 2-байтными таблицами, каждый элемент которых содержит информацию о соответствующей цепочке в таблице штрихов, числе штрихов и (для пропорциональных шрифтов) ширине символа.

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

4) каждый штрих (tick) представляет собой связную цепочку пикселей, не содержащую разрывов и острых углов. В битовом поле каждого штриха кодируются не пиксели, а углы: 00 = прямо; 01 = вперед и вправо; 10 = вперед и влево; 11 = направо (под прямым углом). Для отрисовки конкретного штриха требуется дополнительно задать начальные условия: направление и исходную координату (реперную точку) рисования.

5) в общем случае начальный вектор кодируется 3 битами. Но существуют важные группы штрихов, для которых на направлении можно сэкономить:
- прямые линии: требуют только 2 бит для вектора, и не имеют поворотов;
- центрально-симметричные фигуры (например, квадрат) - требуют только 1 бита для вектора;
- ротационные инварианты (например, точка) - не нуждаются в начальном векторе.
Для этих штрихов предусмотрено специальное кодирование.

работа еще не закончена. детали и конкретные форматы - будут чуть позже, на Вики и здесь. пока что жду комментов.


Top
   
PostPosted: Sat Nov 26, 2011 3:27 pm 
Offline

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


Top
   
PostPosted: Sat Nov 26, 2011 3:52 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
SoUrcerer
Oops, я упустил одно важное слово в заголовке: Немасштабируемые векторные системные шрифты
Я против Юникода в ядре, но вполне "за" расширенную кодировку в подгружаемых и библиотечных шрифтах.
Заполнение (утолщение - второй линией) будет, и много чего еще - формат вполне себе расширяемый. Но необходимость в полноценных масштабируемых шрифтах вовсе не отпадает!

Для системных фонтов пока будут некоторые ограничения: 256 знаков, не более 256 разных штрихов, 32 реперные точки (могут быть разными для каждого шрифта), двухбайтовая кодировка, не более 8 штрихов в символе и общая таблица отрисовки для всех шрифтов - не более 4кбайт.
4 шрифта туда должны влезть, причем каждый шрифт может быть как в моноширинном, так и в пропорциональном представлении.

P.S. Кодирование такого шрифта - сплошной геморрой, надо будет какую-то графическую утилитку замутить.


Top
   
PostPosted: Sat Nov 26, 2011 4:55 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Очень странно. ФС поддерживает хоть капельку Юникод, а системные сообщения не могут быть в нем выведены.


Top
   
PostPosted: Sat Nov 26, 2011 5:09 pm 
Одно с другим слабо связано. Да и 70 функция только лишь возвращать может в юникоде, а принимать путь не может.


Top
   
PostPosted: Sat Nov 26, 2011 5:15 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
Мне и той кодировки, что есть, хватает для прочтения всех мыслимых системных сообщений.

Кому нужны хирагана и иврит внутри ядра - пусть чешут свою репку. Сразу предупреждаю: 8 штрихов в символе - для китайского маловато будет.

Снаружи юникод конечно нужен, не спорю.


Last edited by art_zh on Sat Nov 26, 2011 5:19 pm, edited 1 time in total.

Top
   
PostPosted: Sat Nov 26, 2011 5:17 pm 
Еще 100500 иероглифов тоже недоступны братьям китайцам. Да и насчет иврита - куда-то человек пропал совсем.


Top
   
PostPosted: Sat Nov 26, 2011 5:27 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Хочу кандзи. Чешу свою репку.


Top
   
PostPosted: Tue Nov 29, 2011 12:21 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
(продолжение. Начало - в первом посте)

6) Реперная точка для специальных штрихов (см. п.5) задается абсолютными координатами X, Y.
Для обычных штрихов абсолютные координаты - непозволительная роскошь. Реперная точка (origin) у них кодируется 5-битным номером, т.е. допускается не более 32 разных реперных точек на шрифт.
Code:
формат вставки обычных штрихов в битовое поле символа: (gptick):
bits[15:11] = origin# (0..31)
bits[10: 8] = rotation code (0..7)
bits[ 7: 0] = tick# (32..127)
-- номера 0..31 и 128..256 зарезервированы для специальных штрихов (см. ниже)

формат прямой линии (lntick)
bits[15:12] = X (0..11)
bits[11: 8] = Y (0..15)
bits[ 7: 5] = line code: 000b (short lines, 2..7pix), or 111b (longer lines, 8..15pix)
bits[ 4: 3] = rotation code (0..3)
bits[ 2: 0] = length, pix
-- линий с длиной 0 или 1 пиксел не бывает. их коды зарезервированы для штрихов, инвариантных операции поворота (см. ritick).

формат ротационных инвариант (ritick)
bits[15:12] = X (0..11)
bits[11: 8] = Y (0..15)
bits[ 7: 1] = 000xx00b
bits[ 4: 3] = reserved (currently 00)
bit [ 0 ] : 0 = single pixel; 1 = 8pix ring

формат центрально-симметричных фигур  (cstick)
bits[15:12] = X (0..11)
bits[11: 8] = Y (0..15)
bits[ 7: 3] = 11000b
bit [ 2 ] = rotation: 0 = flat; 1 = diagonal
bits[ 1: 0] = tick#

формат сложносоставных символов  (cxtick)
bits[15:11] = origin# (0..31)
bits[10: 9] = char# (higher 2 bits)
bit [ 8 ] = rotation: 0 = no turn; 1 = turned
bits[ 7: 6] = 10b
bits[ 5: 0] = char# (lower 6 bits)
-- этот тип пока не реализован. Может быть полезен для дополнительного сжатия таблиц рисования,
определяя символы через уже определенные другие символы (b -> q, d -> p, и т.п.)


Top
   
PostPosted: Tue Nov 29, 2011 8:00 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Пощупать где можно? А-версия заработает на не-АМД?


Top
   
PostPosted: Tue Nov 29, 2011 8:35 am 
Если перенести в trunk то вполне может работать - это же не платформа-зависимая часть.


Top
   
PostPosted: Tue Nov 29, 2011 10:05 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Я, конечно, сам такой - ничего не показываю, пока не посчитаю, что можно показывать. Но очень уж посмотреть хочется.


Top
   
PostPosted: Tue Nov 29, 2011 11:52 am 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
SoUrcerer wrote:
Пощупать где можно? А-версия заработает на не-АМД?

Парсер кривой пока, даже не собирается. работаю.
Заливаю в А-код, чтобы не мусорить в основном транке.
Ограничение только одно - 32-битная графика.
На этой неделе можно будет пощупать, заодно сравним скорость отрисовки.

UPD. Уже собирается :)


Top
   
PostPosted: Tue Nov 29, 2011 1:55 pm 
А разве проблемно для 24 бит допилить? Другие разрешения, кроме 24 и 32 в Колибри по факту не используются.


Top
   
PostPosted: Tue Nov 29, 2011 2:27 pm 
Offline
Kernel Developer
User avatar

Joined: Fri Aug 14, 2009 1:46 am
Posts: 1331
Больших проблем с 24-битным режимом не должно быть - отличие только в PutPixel

Серьезная разница только с VGA (и по-моему даже ЕGA еще можно сэмулировать). В DosBoxe ядро не сможет само себя загружать :lol:

Хотя по большому счету все можно свести к тому же putpixel.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 61 posts ]  Go to page 1 2 3 4 5 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:  
cron
Powered by phpBB® Forum Software © phpBB Limited