в принципе, определиться с номерами указаных объектов и команд, их параметрами (в т.ч. по приоритету - то, что часто надо указывать, в начале, то, что редко - в конце, так битфилд короче будет), и можно записывать в BFG(vs) шрифты)
Соответственно, в заголовке файла следует указывать так же подмножество языка, чтобы не путали программы ничего
формат векторной графики
-
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мне кажется, что полезнее делать, чем бесконечно теоретизировать. С начала обсуждения прошло 5 месяцев. За это время можно было сделать (по крайней мере, неполную) поддержку того же SVG. Или портировать готовую реализацию.
При затратах времени, разумеется.
При затратах времени, разумеется.
попытался на php организовать генерирование таких файлов - столкнулся с совершеннейшей неприспособленностью php к работе с низкоуровневыми структурами с одной стороны, и сложностью генерации битовых полей, что связано, в первую очередь, с необходимостью заранее указывать то, что может быть посчитано только в дальнейшем.
Однако в последнем ничего удивительного нет, так как формат битовых полей был создан не с учетом простой генерации, но с учетом простого чтения и экономии в объеме данных. Я не хочу сказать что генерация невозможна, но хочу сказать что она будет дольше чтения, ввиду того, что приходится проходиться по сгенерированным битам дважды - в ту и в другую сторону. Готовый алгоритм на пхп опубликую (как генерации, так и чтения), благо у знакомых с Си людей не возникает проблем с чтением php-исходников обычно.
Однако в последнем ничего удивительного нет, так как формат битовых полей был создан не с учетом простой генерации, но с учетом простого чтения и экономии в объеме данных. Я не хочу сказать что генерация невозможна, но хочу сказать что она будет дольше чтения, ввиду того, что приходится проходиться по сгенерированным битам дважды - в ту и в другую сторону. Готовый алгоритм на пхп опубликую (как генерации, так и чтения), благо у знакомых с Си людей не возникает проблем с чтением php-исходников обычно.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
зато, написание на PHP позволит:
1) "компилировать" изображения из SVG на сервере, ввиду присутствия на нем PHP с одной стороны, и присутствия в PHP средств работы с XML - с другой.
2) создать онлайн-редактор или конвертер (см. п. 1) таких изображений.
Одно из подмножеств формата я планирую в дальнейшем использовать для задания и хранения механических систем (в учебной и научной работе), благо он достаточно мощен для этого должен получиться (подмножество может иметь очень много своих функций (а именно 2^(8*4), лень считать), не "засоряя" основной формат, т.к. использует нулевую функцию).
[offtop]И да, надеюсь, что буду использовать в ней (работе) Колибри =)[/offtop]
P.S. битовые поля почти генерятся, осталось сделать второй проход. К сожалению, алгоритм, ввиду моего незнания PHP, крайне неэффективен, и для ассемблерной версии конвертера/парсера придется писать другой, а не адаптировать этот. Хотя, тоже вариант. Просто я могу не найти времени на асм-версию, хочу хоть PHP доделать и выложить.
1) "компилировать" изображения из SVG на сервере, ввиду присутствия на нем PHP с одной стороны, и присутствия в PHP средств работы с XML - с другой.
2) создать онлайн-редактор или конвертер (см. п. 1) таких изображений.
Одно из подмножеств формата я планирую в дальнейшем использовать для задания и хранения механических систем (в учебной и научной работе), благо он достаточно мощен для этого должен получиться (подмножество может иметь очень много своих функций (а именно 2^(8*4), лень считать), не "засоряя" основной формат, т.к. использует нулевую функцию).
[offtop]И да, надеюсь, что буду использовать в ней (работе) Колибри =)[/offtop]
P.S. битовые поля почти генерятся, осталось сделать второй проход. К сожалению, алгоритм, ввиду моего незнания PHP, крайне неэффективен, и для ассемблерной версии конвертера/парсера придется писать другой, а не адаптировать этот. Хотя, тоже вариант. Просто я могу не найти времени на асм-версию, хочу хоть PHP доделать и выложить.
почти готова генерация на пхп BFGvs. функция требуют объявленных глобальных переменных:
1) массив возможных объектов и их свойств - в общем, правила формата (пример):
2) массив нумерации функций - вынесен отдельно для удобной перетасовки (пример):
ну и на вход принимается описание картинки (в такой вид нужно привести SVG для конвертации через этот скрипт):
на что функция возвращает строку в таком виде "{424647}{01}{0000004e}{01}[10010100][00010010]{0190}{05}{80}{02}[01001001][00000000]{40}{80}{54}{70}", где в квадратных скобках бинарные числа, в фигурных - шеснадцатиричные.
что еще не сделано:
Длина в заголовке указывается неверно (она указыватеся не для готового файла, а для строки, которую выдает функция).
Цветовые схемы кроме argb не поддерживаются, ahls будет добавлена позже.
Еще нет опций оптимизации с искажением (например, сохранения цвета argb(1,254,254,254) как argb(0,255,255,255), что сократит требуемый для хранения цвета объем в четыре раза), происходит только оптимизация без искажения.
Не знаю как в PHP выдать двоичный файл, потому выдается текстом.
Парсер тоже будет, позже.
Пока не выкладываю скрипты, но кому надо вдруг - просите
ADDED: строки сделаны, вычеркнул.
длину атрибутов функции указывать и не надо, вычеркнул.
1) массив возможных объектов и их свойств - в общем, правила формата (пример):
Code: Select all
$bfg_rules=array(
'zeroobject'=>array(),
'rectangle'=>array(
'x position',
'y position',
'x size',
'y size',
'rotation',
'fillcolor',
'thickness',
'strokecolor',
'round radius x',
'round radius y',
'fill transparency',
'stroke transparency',
'filltexture',
'strokefigure'
),
'ellipse'=>array(
'x position',
'y position',
'x radius',
'y radius',
'rotation',
'fillcolor',
'thickness',
'strokecolor',
'fill transparency',
'stroke transparency',
'filltexture',
'strokefigure'
)
);
Code: Select all
$bfg_numbers=array(
'zeroobject'=>0,
'rectangle'=>1,
'ellipse'=>2
);
Code: Select all
array(
array('type'=>'rectangle','parameters'=>array(
array('name'=>'x size','type'=>'integer','value'=>400),
array('name'=>'thickness','type'=>'integer','value'=>5),
array('name'=>'strokecolor','type'=>'argb color','value'=>array(170,0,0,0)))),
array('type'=>'ellipse','parameters'=>array(
array('name'=>'x radius','type'=>'float','value'=>0.25),
array('name'=>'x position','type'=>'float','value'=>0.5),
array('name'=>'y position','type'=>'float','value'=>0.33),
array('name'=>'fill color','type'=>'argb color','value'=>array(85,255,0,0))))
)
что еще не сделано:
Длина в заголовке указывается неверно (она указыватеся не для готового файла, а для строки, которую выдает функция).
Цветовые схемы кроме argb не поддерживаются, ahls будет добавлена позже.
Еще нет опций оптимизации с искажением (например, сохранения цвета argb(1,254,254,254) как argb(0,255,255,255), что сократит требуемый для хранения цвета объем в четыре раза), происходит только оптимизация без искажения.
Не знаю как в PHP выдать двоичный файл, потому выдается текстом.
Парсер тоже будет, позже.
Пока не выкладываю скрипты, но кому надо вдруг - просите
ADDED: строки сделаны, вычеркнул.
длину атрибутов функции указывать и не надо, вычеркнул.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
в SVG окружности, как как и в SWF, похоже, задаются с помощью кривых =(
ну да ладно, благо от кривых мы не отказываемся, просто конвертированные из SVG будут не настолько оптимальны, насколько это позволяет BFG(vs).
А вообще там ничего сложного в конвертации с помощью PHP, по крайней мере, нет. Ну сперва генерацию с парсингом доделаю, потом уже конвертация туда-обратно...
P.S. парсинг хочу в качестве д/з другу, желающему научиться программировать на Си, дать =)
-Сито- Си то поближе к Колибри будет, чем PHP, а я первого не знаю в достаточной мере.
Таки да, координаты лучше и правда вещественные)
ну да ладно, благо от кривых мы не отказываемся, просто конвертированные из SVG будут не настолько оптимальны, насколько это позволяет BFG(vs).
А вообще там ничего сложного в конвертации с помощью PHP, по крайней мере, нет. Ну сперва генерацию с парсингом доделаю, потом уже конвертация туда-обратно...
P.S. парсинг хочу в качестве д/з другу, желающему научиться программировать на Си, дать =)
-Сито- Си то поближе к Колибри будет, чем PHP, а я первого не знаю в достаточной мере.
Таки да, координаты лучше и правда вещественные)
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
в массив правил формата будут добавлены дефолтные значения (зачем они для чтения, думаю, понятно, а для генерации - чтобы можно было во входном массиве их указывать, а в файл они не сохранялись).
Теперь, давайте поговорим (я надеюсь, это не будет монолог) о координатах. У меня такой вариант есть:
есть два поля под каждую координату/размер (т.е. когда указано лишь одно, теряется лишь один бит на второе). Первое поле - числитель, второе - знаменатель. Когда второе не задано (дефолтное значение ноль) или равно нулю, то первое поле содержит размеры в тех же единицах, в которых задан размер поля.
Если задан только второй параметр, то первый равен нулю, и размер/координата равен размер поля*У/Х, где У это число, заданное в параметре, Х - 2 в степени (8*число байт параметра), т.е. если задано 127 в одном байте, то это половина размера поля.
Если заданы оба параметра, то размер/координата равно размер поля*первый пар-р/второй пар-р.
Вроде, получается достаточно гибко, объединяя все три предполагаемые мной варианта. Как вам?
Теперь, давайте поговорим (я надеюсь, это не будет монолог) о координатах. У меня такой вариант есть:
есть два поля под каждую координату/размер (т.е. когда указано лишь одно, теряется лишь один бит на второе). Первое поле - числитель, второе - знаменатель. Когда второе не задано (дефолтное значение ноль) или равно нулю, то первое поле содержит размеры в тех же единицах, в которых задан размер поля.
Если задан только второй параметр, то первый равен нулю, и размер/координата равен размер поля*У/Х, где У это число, заданное в параметре, Х - 2 в степени (8*число байт параметра), т.е. если задано 127 в одном байте, то это половина размера поля.
Если заданы оба параметра, то размер/координата равно размер поля*первый пар-р/второй пар-р.
Вроде, получается достаточно гибко, объединяя все три предполагаемые мной варианта. Как вам?
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
И снова здравствуйте. Кажется, ещё никто в этой теме не упоминал HVIF - Haiku Vector Icon Format (обзор на хабре). Формат прост и компактен - колибри-стайл, а также уже используется в Haiku, так что доступна пара сотен свободных HVIF иконок, и существует как минимум один графический векторный редактор, напрямую работающий с этим форматом.
Мне кажется, целесообразнее использовать его в KolibriOS, нежели придумывать свой формат.
Мне кажется, целесообразнее использовать его в KolibriOS, нежели придумывать свой формат.
для иконок неплохо, но явно недостаточно для всего прочего (механических систем с высокой точностью позиционирования, например, или для построения интерфейсов приложений). А для иконок, повторюсь, да, круто. Приложение ICON можно изрядно доработать с учетом. Но я не уверен, что оно будет эффективнее растра в плане быстродействия
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Who is online
Users browsing this forum: No registered users and 8 guests