Прикрутил arc/pie/chord/polyline, приделал пересчёт координат (теперь надо прицепить кусочек инициализации для правильного масштабирования). Из серьёзного остались битмапы и текст. Ну и с clip/mask в SVG надо как-то разбираться.

Пришлось вспомнить про то, что в MF многое сделано через задний проход, начиная от PolyPolygon и до идиотства с "объектами". Надо приделать выдачу  отсутствующих в SVG Pie и Chord, добавить пересчёт координат в соответствии с текущим DC, добавить выдачу текста.

Вместо выяснения того как реализовывать нужные фичи в SVG  путём чтения документации, попытался сгенерить нужное в Inkscape. Удалось только со штрих-пунктиром (stroke-dasharray). Попытки даже не нарисовать со стандартным шаблоном заливки, а хотя бы просто скопировать сгенерённое ранее позорно провалились. Попутно выяснилось, что Cairo генерит SVG довольно неоптимально, а Inkscape пихает в файл всякую случайную фигню.

.. вы бы так работать не смогли бы...(с) анекдот про Горбача

Вот интересно... Если б себестоимость хранения здоровенной коробки оказалась выше, привёз бы мне UPS её в четверг вечером или просто цена на "стандарт" была бы такой же как на "экспресс"?

Во-первых, вот: http://arkanoid.livejournal.com/284831.html

Вчера прибежал на irc.gimp.net очередной спамер, но видимо только туда, где было достаточно народу. Поэтому #gimp и #vala зацепило, а, например, #gnumeric -- нет. Запостил какую-то рассистскую бредятину про негров. Оказался не ботом, а живым мексиканцем. В общем "ничего личного, примерно 2500 песо в неделю" (т.е. чуть поменьше USD200).
Вероятно на такие деньжищи неплохо живёт, а то может и успешным специалистом с каким-нибудь модным названием должности числится.

А между тем в gnumeric-list (по утверждению gmorten) 99% of the posts from non-members are from .ru and they are spam. (Это было пояснением к вопросу почему 'gmorten wonders why we don't auto-discard all posts from .ru').

Франц вольно пересказал с немецкого кусок документации по формату Micrografx. В очередной раз переделал колупалку FH, на этот раз на колупание DRW. Перенёс из документации указанные названия записей, про остальные остаётся догадываться. Нашёл соответствия между типами "символов" и формами. Занятно, что аналог close_path у них в одном ряду с группами и остальными формами вроде прямоугольников, эллипсов и пр.
В общем на поддержку импорта этого формата в Шкрибусе видимо уже можно твёрдо рассчитывать.

Встретились вечером с Jody в UofT, где он рассказывал группке студентов про gnumeric, goffice и libgsf. Студенты будут делать какие-то свои софтовые проекты на базе этого кода. Это не первый случай такого использования gnumeric в учебном процессе, но впервые в Торонто, что даёт существенно больше возможностей для Jody направлять энергию в правильное русло. Зафлипал бОльшую часть рассказа. Опасался за звук, поскольку дело было в некоей большой аудитории, в другой части которой две-три банды каких-то ещё студентов изрядно шумничали, но вроде б всё слышно.
После мероприятия потрепались на темы Escher, VBA byte-code, WMF/EMF, канвасов и прочих разных интересностей. VBA byte-code надо расколдовать, WMF/EMF утрамбовать в какую-нибудь библиотеку.
Договорились о возможности добавить в libgsf специфический inflate/deflate для VSD/VSS.

Разглядываю сырцы разных hexeditor-ов, чтоб понять как правильно делать универсальную колупалку.

Посмотрел на файлы papyrus. Внешний слой -- TLV. Всегда бы так -- пятнадцать минут на выкидывание лишнего из ковыряли FH для получения правильной ковырялки PAP.

Кристоф указал на freefreehand.org. Ребята хотят, чтоб Адоба открыла исходные тексты FreeHand передав ненужный и брошенный софт в хорошие руки сообщества. Хотя из этой затеи вряд ли что-то выйдет (не такие дураки в Адобе, чтоб своими собственными свободными руками задушить свой же любимый Иллюстратор), сама постановка вопроса как мне кажется не выглядит таким безумием как было бы лет 10 назад.

Занятно так же то, что вдохновителями этого дела похоже стали ущербные макофилы, да к тому же ещё и копирасты.
"И не развяжешь узла
Одно выбирай:
Путь под трамвай!"

Ковырялка расковыряла файл с примерно 57 тысячами чанков.  В файле оказалось два новых типа чанков, ещё для пары типов нашёлся более правильный способ вычисления размера. Прояснился новый вариант вычисления размера: для чанков Oval не удавалось обнаружить в самих чанках ничего объясняющего разницу в размерах. "Поначалу-то сперва, подписался я за два" показалось, что разница в том указывает ли второй word на чанк Group или нет. Не сошлось. Пока сходится на том, указывает ли первый word на ElemPropLst. Вероятно аналогичным образом ведёт себя Rectangle, может быть Path и что-нибудь ещё.

abbra предположил, что способ определения размера чанка может быть каким-то образом закодирован в ID в словаре. Чего-либо подобного обнаружить не удалось, зато в процессе изучения обратил внимание на то, что есть чанки TextBlok и TextBlock =)

Разбиралка разбирает многотысячечанковые файлы. Новые чанки попадаются всё реже, зато периодически выплывают разные версии уже известных чанков. Разнобой потрясный. Такое наверное могло бы приключиться, если бы программу писали 3-4 почти совсем независимые друг от друга группы. Даже координаты задаются через жопу.
Казалось бы, используя старший бит в двойном слове можно было бы указать плюс-минус 2^31 в любую сторону. Если всё измерять в пикселях, то даже простого слова бы хватило. Но нет! Отважные бармалеи всегда идут своим особенным путём. В данном случае нули сдвинуты на разные величины для X и Y куда-то в район минус полутора тысяч пикселей. Т.е. почти, но не в точности туда, где заканчивается "поле". Понятно, что начало координат обычно в левом (верхнем или нижнем зависит от того в Лиллипутии или Блефуску учился хвала-изобретатель) углу, но при такой шкале на это можно было бы и наплевать. Любопытно, что значения не меняются при изменении разрешения принтера, что должно бы приводить к каким-нибудь последствиям.