Задумка зародилась здесь, но в том сабже была оффтопиком.
По ходу реализации конкретный формат новых шрифтов и код парсера много раз менялась: код цепочки из 3-битного ужался до 2бит на угол, максимальный размел символа - до 12х21, введены стандартные реперные точки и обработка симметричных линий, и т.п.
Но основные идеи во многом остаются прежними:
1) шрифты состоят из символов (chars), символы - из штрихов (ticks); отдельные штрихи могут быть общими для разных символов и даже шрифтов.
2) шрифты кодируются 256-элементными 2-байтными таблицами, каждый элемент которых содержит информацию о соответствующей цепочке в таблице штрихов, числе штрихов и (для пропорциональных шрифтов) ширине символа.
3) каждый элемент в таблице штрихов - это 2-байтовое битовое поле, содержащее информацию о реперной точке (откуда начинается рисование), начальном векторе, и номере штриха. Форматы этих битовых полей различаются для разных ротационных групп штрихов (см. ниже)
4) каждый штрих (tick) представляет собой связную цепочку пикселей, не содержащую разрывов и острых углов. В битовом поле каждого штриха кодируются не пиксели, а углы: 00 = прямо; 01 = вперед и вправо; 10 = вперед и влево; 11 = направо (под прямым углом). Для отрисовки конкретного штриха требуется дополнительно задать начальные условия: направление и исходную координату (реперную точку) рисования.
5) в общем случае начальный вектор кодируется 3 битами. Но существуют важные группы штрихов, для которых на направлении можно сэкономить:
- прямые линии: требуют только 2 бит для вектора, и не имеют поворотов;
- центрально-симметричные фигуры (например, квадрат) - требуют только 1 бита для вектора;
- ротационные инварианты (например, точка) - не нуждаются в начальном векторе.
Для этих штрихов предусмотрено специальное кодирование.
работа еще не закончена. детали и конкретные форматы - будут чуть позже, на Вики и здесь. пока что жду комментов.
Немасштабируемые векторные шрифты
А может все-таки сделать больше, чем 256 символов в шрифте?
Такой вариант, как я уже говорил, хорошо может подойти для небольших экранных шрифтов. Но почему бы не сделать возможность заполнения символа? Тогда шрифты можно будет с чистой совестью масштабировать.
Такой вариант, как я уже говорил, хорошо может подойти для небольших экранных шрифтов. Но почему бы не сделать возможность заполнения символа? Тогда шрифты можно будет с чистой совестью масштабировать.
SoUrcerer
Oops, я упустил одно важное слово в заголовке: Немасштабируемые векторные системные шрифты
Я против Юникода в ядре, но вполне "за" расширенную кодировку в подгружаемых и библиотечных шрифтах.
Заполнение (утолщение - второй линией) будет, и много чего еще - формат вполне себе расширяемый. Но необходимость в полноценных масштабируемых шрифтах вовсе не отпадает!
Для системных фонтов пока будут некоторые ограничения: 256 знаков, не более 256 разных штрихов, 32 реперные точки (могут быть разными для каждого шрифта), двухбайтовая кодировка, не более 8 штрихов в символе и общая таблица отрисовки для всех шрифтов - не более 4кбайт.
4 шрифта туда должны влезть, причем каждый шрифт может быть как в моноширинном, так и в пропорциональном представлении.
P.S. Кодирование такого шрифта - сплошной геморрой, надо будет какую-то графическую утилитку замутить.
Oops, я упустил одно важное слово в заголовке: Немасштабируемые векторные системные шрифты
Я против Юникода в ядре, но вполне "за" расширенную кодировку в подгружаемых и библиотечных шрифтах.
Заполнение (утолщение - второй линией) будет, и много чего еще - формат вполне себе расширяемый. Но необходимость в полноценных масштабируемых шрифтах вовсе не отпадает!
Для системных фонтов пока будут некоторые ограничения: 256 знаков, не более 256 разных штрихов, 32 реперные точки (могут быть разными для каждого шрифта), двухбайтовая кодировка, не более 8 штрихов в символе и общая таблица отрисовки для всех шрифтов - не более 4кбайт.
4 шрифта туда должны влезть, причем каждый шрифт может быть как в моноширинном, так и в пропорциональном представлении.
P.S. Кодирование такого шрифта - сплошной геморрой, надо будет какую-то графическую утилитку замутить.
Очень странно. ФС поддерживает хоть капельку Юникод, а системные сообщения не могут быть в нем выведены.
Одно с другим слабо связано. Да и 70 функция только лишь возвращать может в юникоде, а принимать путь не может.
Мне и той кодировки, что есть, хватает для прочтения всех мыслимых системных сообщений.
Кому нужны хирагана и иврит внутри ядра - пусть чешут свою репку. Сразу предупреждаю: 8 штрихов в символе - для китайского маловато будет.
Снаружи юникод конечно нужен, не спорю.
Кому нужны хирагана и иврит внутри ядра - пусть чешут свою репку. Сразу предупреждаю: 8 штрихов в символе - для китайского маловато будет.
Снаружи юникод конечно нужен, не спорю.
Last edited by art_zh on Sat Nov 26, 2011 5:19 pm, edited 1 time in total.
Еще 100500 иероглифов тоже недоступны братьям китайцам. Да и насчет иврита - куда-то человек пропал совсем.
Хочу кандзи. Чешу свою репку.
(продолжение. Начало - в первом посте)
6) Реперная точка для специальных штрихов (см. п.5) задается абсолютными координатами X, Y.
Для обычных штрихов абсолютные координаты - непозволительная роскошь. Реперная точка (origin) у них кодируется 5-битным номером, т.е. допускается не более 32 разных реперных точек на шрифт.
6) Реперная точка для специальных штрихов (см. п.5) задается абсолютными координатами X, Y.
Для обычных штрихов абсолютные координаты - непозволительная роскошь. Реперная точка (origin) у них кодируется 5-битным номером, т.е. допускается не более 32 разных реперных точек на шрифт.
Code: Select all
формат вставки обычных штрихов в битовое поле символа: (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, и т.п.)
Пощупать где можно? А-версия заработает на не-АМД?
Если перенести в trunk то вполне может работать - это же не платформа-зависимая часть.
Я, конечно, сам такой - ничего не показываю, пока не посчитаю, что можно показывать. Но очень уж посмотреть хочется.
Парсер кривой пока, даже не собирается. работаю.SoUrcerer wrote:Пощупать где можно? А-версия заработает на не-АМД?
Заливаю в А-код, чтобы не мусорить в основном транке.
Ограничение только одно - 32-битная графика.
На этой неделе можно будет пощупать, заодно сравним скорость отрисовки.
UPD. Уже собирается
А разве проблемно для 24 бит допилить? Другие разрешения, кроме 24 и 32 в Колибри по факту не используются.
Больших проблем с 24-битным режимом не должно быть - отличие только в PutPixel
Серьезная разница только с VGA (и по-моему даже ЕGA еще можно сэмулировать). В DosBoxe ядро не сможет само себя загружать
Хотя по большому счету все можно свести к тому же putpixel.
Серьезная разница только с VGA (и по-моему даже ЕGA еще можно сэмулировать). В DosBoxe ядро не сможет само себя загружать
Хотя по большому счету все можно свести к тому же putpixel.
Who is online
Users browsing this forum: No registered users and 1 guest