Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Пт мар 24, 2017 8:55 pm

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 61 сообщение ]  На страницу 1 2 3 4 5 След.
Автор Сообщение
СообщениеДобавлено: Сб ноя 26, 2011 2:48 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Задумка зародилась здесь, но в том сабже была оффтопиком.

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

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

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

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

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

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

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

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


Вернуться к началу
СообщениеДобавлено: Сб ноя 26, 2011 3:27 pm 
Не в сети

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


Вернуться к началу
СообщениеДобавлено: Сб ноя 26, 2011 3:52 pm 
Не в сети
Kernel Developer
Аватара пользователя

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

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

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


Вернуться к началу
СообщениеДобавлено: Сб ноя 26, 2011 4:55 pm 
Не в сети

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


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


Вернуться к началу
   
СообщениеДобавлено: Сб ноя 26, 2011 5:15 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Мне и той кодировки, что есть, хватает для прочтения всех мыслимых системных сообщений.

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

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


Последний раз редактировалось art_zh Сб ноя 26, 2011 5:19 pm, всего редактировалось 1 раз.

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


Вернуться к началу
   
СообщениеДобавлено: Сб ноя 26, 2011 5:27 pm 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Хочу кандзи. Чешу свою репку.


Вернуться к началу
СообщениеДобавлено: Вт ноя 29, 2011 12:21 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
(продолжение. Начало - в первом посте)

6) Реперная точка для специальных штрихов (см. п.5) задается абсолютными координатами X, Y.
Для обычных штрихов абсолютные координаты - непозволительная роскошь. Реперная точка (origin) у них кодируется 5-битным номером, т.е. допускается не более 32 разных реперных точек на шрифт.
Код:
формат вставки обычных штрихов в битовое поле символа: (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, и т.п.)


Вернуться к началу
СообщениеДобавлено: Вт ноя 29, 2011 8:00 am 
Не в сети

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


Вернуться к началу
СообщениеДобавлено: Вт ноя 29, 2011 8:35 am 
Если перенести в trunk то вполне может работать - это же не платформа-зависимая часть.


Вернуться к началу
   
СообщениеДобавлено: Вт ноя 29, 2011 10:05 am 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
Я, конечно, сам такой - ничего не показываю, пока не посчитаю, что можно показывать. Но очень уж посмотреть хочется.


Вернуться к началу
СообщениеДобавлено: Вт ноя 29, 2011 11:52 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
SoUrcerer писал(а):
Пощупать где можно? А-версия заработает на не-АМД?

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

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


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


Вернуться к началу
   
СообщениеДобавлено: Вт ноя 29, 2011 2:27 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
Больших проблем с 24-битным режимом не должно быть - отличие только в PutPixel

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

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


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 61 сообщение ]  На страницу 1 2 3 4 5 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB