Немасштабируемые векторные шрифты

Kernel-side graphics support
  • А может все-таки сделать больше, чем 256 символов в шрифте?
    Такой вариант, как я уже говорил, хорошо может подойти для небольших экранных шрифтов. Но почему бы не сделать возможность заполнения символа? Тогда шрифты можно будет с чистой совестью масштабировать.
  • SoUrcerer
    Oops, я упустил одно важное слово в заголовке: Немасштабируемые векторные системные шрифты
    Я против Юникода в ядре, но вполне "за" расширенную кодировку в подгружаемых и библиотечных шрифтах.
    Заполнение (утолщение - второй линией) будет, и много чего еще - формат вполне себе расширяемый. Но необходимость в полноценных масштабируемых шрифтах вовсе не отпадает!

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

    P.S. Кодирование такого шрифта - сплошной геморрой, надо будет какую-то графическую утилитку замутить.
  • Очень странно. ФС поддерживает хоть капельку Юникод, а системные сообщения не могут быть в нем выведены.
  • Одно с другим слабо связано. Да и 70 функция только лишь возвращать может в юникоде, а принимать путь не может.
  • Мне и той кодировки, что есть, хватает для прочтения всех мыслимых системных сообщений.

    Кому нужны хирагана и иврит внутри ядра - пусть чешут свою репку. Сразу предупреждаю: 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 разных реперных точек на шрифт.

    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 ядро не сможет само себя загружать :lol:

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

    Users browsing this forum: No registered users and 4 guests