konstantin_666: "Тем более, что они собрались всё флэшем завешать." - кто Они? Теория заговора?)

HTML-язык разметки текста. Им размечают текст. Текст им размечают. Гипертекст. Зачем в панелях гипертекст? Впрочем, в данной теме панели (в отрыве от сабжа) - оффтоп.

А здесь выбираем готовый или создаем новый (я за новый, но если найдем хороший готовый - почему нет) формат для _векторной_графики_. При чем здесь язык разметки гипертекста вообще?

Freeman, понимаю идею, но вот какие есть соображения - если сделать такое разделение, какое предложил я, то можно считать все рисуемые элементы необязательными, все нерисуемые - обязательными.

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

А нерисование рисуемого объекта не повлияет ни на что, кроме самого объекта.

Про длину данных - мысль верная, это может быть нужным. Но если у парсера есть данные о возможных объектах (хотя бы о свойствах они должны быть - иначе биты в битмаске ничего парсеру не скажут), то есть информация и о том, какое поле свойств какой длины, а располагая битмаской, можно посчитать сумму длинн свойств, и довольно быстро обойти объект, не считывая самих свойств (только битмаску).

Андрей Михайлович, (кстати, классный ник, одно удовольствие обращаться) все проще даже)
0х00 - некий графический объект дополнительный (он не обязательно не влез! может, некая программа захотела свой тип объекта в своих файлах использовать - пусть нулевой объект и будет для этих целей использоваться), 0xFF - то же для неграфических (если мы таки введем разделение. если нет - пусть будет объектом "конец рисунка", с какими-то, на всякий случай, своими свойствами), а среди свойств (тут про запас можно для битмапа хоть двойное слово отдать. Или так - в первом байте битмапа один из бит пусть говорит, есть ли еще байт бисмапа - и так до 4х байт) будет его номер

Asper, в начале где-то был пример рисунка в где-то 43 байта. В разработке формата врядли эта цифра изменится, но пусть будет 50 байт. Сколько будет занимать такой же рисунок в формате SWF (без заголовков файла, и отдельно с)? можно и прикрепить его сюда. Конечно, мусор от редакторов надо выкинуть (если это возможно, если нет - это в минус формату, я считаю, в данном контексте), а лучше написать без редакторов (не настаиваю, т.к. формата и степени его сложности я не представляю), но при этом чтобы он продолжал валидно воспроизводиться просмотрщиками (и без ошибок с ворнингами), так же я бы взглянул на вывод gnash при парсинге этого файла (тоже очень желательно приложить, у меня нет под рукой компьютера, чтобы сделать это самому).

Эти просьбы связаны с тем, что этот вариант не отбрасывается

А теперь по теме "разрабатываемого" формата.
Gluk почему-то не учёл один мааааленький ньюанс.
Если то, что мы собираемся создать является форматом данных, то и начинать мы должны с типов этих самых данных.
Если формат и размер операндов полностью будет определять команда, то формат получится очень ограниченым и цитирую: "избыточным" (то есть полным нулей, которые нужно сжимать).
Мало того, это приведёт к отсутствию выравнивания объектов. Чем это грозит? Полной несовместимостью!
Например, решили мы сэкономить пару килобайтов в библиотеке и выбросили оттуда пару определений команд. Парсер доходит до средины документа и встречает неизвестную команду. Всё. Ошибка (или даже зависание).
Данная проблема существует во практически во всех парсерах байт-кода (в том числе и флэш).
Это значит, что совместимость файла и парсера должна быть 100% (в случае флэш готовьте 4 Мб под библиотеку).
Правда, если вы собираетесь исключительно "наращивать" библиотеку, можно довольствоваться обратной совместимостью.

Выходы есть: указывать размер операндов (как в машинном коде), добавлять сигнатуры завершения команды (опасно) и т.п.
Всё это только увеличит размер файла.
А кто-то до сих пор считает "" человеко-понятностью.

И последнее: а как насчёт типов, например string?

Ok, завтра отпишусь.

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

konstantin_666: "Если формат и размер операндов полностью будет определять команда, то формат получится очень ограниченым и цитирую: "избыточным" (то есть полным нулей, которые нужно сжимать)." - каких нулей? которые в битмаске? так это биты. Как вы будете сжимать биты? других нулей не нашел и не смог придумать

"Например, решили мы сэкономить пару килобайтов в библиотеке и выбросили оттуда пару определений команд. Парсер доходит до средины документа и встречает неизвестную команду. Всё. Ошибка (или даже зависание).
Данная проблема существует во практически во всех парсерах байт-кода (в том числе и флэш)." - в постах к Freeman'у я описал поведение программы в такой ситуации. И там нет пункта "зависнуть"
А вообще да, команды, описанные в спецификации обязаны обрабатываться в программе, заявляющей что она умеет работать с таким форматом, соответствующим образом. И если автор программы нарочно нарушает требования спецификации - это целиком и полностью на его совести, думаю, пользователи откажутся не от формата, а от программы (формат может быть и внутренним - тогда пользователь и не знает что там за формат используется), если она падает или зависает там, где другая программа ни падает, ни зависает.

"И последнее: а как насчёт типов, например string?" - а что насчет них?

Gluk, тогда формат можно рассматривать как компилированный SVG, по аналогии с CHM. И чтобы не городить огород, взять стандарт SVG и на его основе сделать стандарт двоичной кодификации. Тут сразу и число объектов, и атрибуты "посчитаются" (256 или больше). Иначе беспредметный спор.

Исхожу из того, что в комитете, разрабатывающем SVG, не дубы сидят, и наверняка собаку на векторной графике съели. В первой версии его можно поддержать не полностью, для того и совместимость.

Соответственно, для работы с форматом нужны компилятор и декомпилятор его в SVG. Сам формат, как понимаю, в памяти будет представлять некий аналог DOM.

Кстати, для SVG вроде стандартизирован SVZ (или как-то так), представляющий собой сжатый XML. Но сжимать можно и компилированный вариант, если есть чем.

konstantin_666, когда я писал предыдущий пост, выделенной жирным цветом фразы не было, с ней чуть понятнее.
"Это значит, что совместимость файла и парсера должна быть 100% (в случае флэш готовьте 4 Мб под библиотеку)." - вот поэтому формат надо не "разрабатывать", а разрабатывать, чтобы не приходилось его постоянно изменять. Вообще форматы не меняются, а появляются новые версии, и обычно это делается только с целью добавить фич и исправить существующие проблемы.
Парсить такой формат программно удобно, и код явно не займет 4 мегабайта. К тому же КоОС это такая ОС, в которой почти все программы уже входят в дистрибутив. Тот, кто собирает дистрибутив, может и проследить чтобы в него не входили программы и библиотеки несовместимых версий (у нас провряет все сообщество на ночных сборках), и уведомить автора программы или библиотеки о том, что надо бы предоставить версию поновее (а если код есть на свн, и лицензия позволяет, это может сделать любой). Такое невозможно в проприетарных флэшплеерах, отсюда проблемы

Gluk "каких нулей? которые в битмаске? " - тех, байтов которые в данных

Freeman "SVG вроде стандартизирован SVZ" - W3C, они и хтмл разработали, который Вы сейчас браузером грузите.

А теперь вспомните сообщения типа: "невозможно отобразить, обновите флэш-плеер"

"В первой версии его можно поддержать не полностью, для того и совместимость." -в этом и заключается преимущество SVG, в любом случае он покажет все графические объекты, которые поддерживает
То же самое и с HTML. Вы видели хоть раз сообщение: "формат HTML-страницы не поддерживается"?

Freeman, мы не будем добавлять в формат те вещи, которые не сможем реализовать до следующей версии формата, а в таком варианте - бинарный SVG - обязаны реализовать. Да, в том комитете неглупые люди, и они выбрали XML, и исходя из этого придумывают всякие вещи. У нас же тут нет XML (например, весьма ограниченная вложенность), поэтому не всякие вещи из SVG нам удобно и хорошо использовать.

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

konstantin_666, в примере (который 43 байта) покажите эти нули. Или в своем (каркас спецификации предоставлен, номера команд берите любые).

konstantin_666, "W3C, они и хтмл разработали, который Вы сейчас браузером грузите."
- Nokia и 3310 разработала, который меньше пяти лет мало у кого прослужил (или мог бы прослужить), и работал много дней без подзарядки, так почему вы не в восторге от N97?
- Microsoft и XP разработала, которую без сомнения можно назвать (в свое время) очень удачной ОС, и даже сейчас многие остаются на ней. Так почему вы не в восторге от Vista?

впрочем, я не об этом, SVG хорош, но не для Колибри

"1[10110000 -1байт](400 -2байта)(180 -1байт)(5 -2байта)2[10101100 -1байт](100 -2байта)(80ff0000 -4байта)(150 -2байта)(200 -2байта)2[10101100 -1байт](100 -2байта)(8000ff00 -4байта)(250 -2байта)(270 -2байта)2[10101100 -1байт](100 -2байта)(800000ff -4байта)(250 -2байта)(130 -2байта)"
А вообще пример явно неправдоподобный.
И что это за "80"?

W3C- некоммерческая организация, единственное на чём она держится- её принципы. Поэтому она их и придерживается. Поэтому и продукты выходят одинаково стабильные и совместимые.