Создание программы оптимизации svg-файлов

[andrew_bye]

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

На данный момент, наиболее функциональным средством очистки и оптимизации svg-файлов является консольная утилита Scour, написанная на втром питоне, а также ее реализация в Inkscape (Save as... -> Optimized SVG). Но им присущ ряд недостатков, на которых пока останавливаться не буду.

С учетом изложенного, хочу предложить всем желающим принять участие в создании проекта, суть которого будет заключаться в разработке графической утилиты, которая сможет предоставить пользователям максимально удобные и гибкие возможности по очистке и оптимизации svg-файлов в пакетном режиме.

В данной утилите считаю целесообразным использовать:

- для GUI - Qt4, поскольку на данный момент нет смысла использовать GTK+ из-за долгоиграющего перехода версий и, кроме того, Qt4 планируется включить в состав базовой системы Ubuntu. Так что, как ни крути, как ни ворочай, а Qt4 - наиболее оптимальный выбор для данных целей.

- для непосредственной обработки файлов  - Perl, поскольку у него есть весьма шустрый и функциональный парсер XML::Twig. Python отбрасываю опять-таки из-за имеющего место перехода версий.

В общем жду конструктивных предложений.

[RazrFalcon]

1) perl будет запускаться как отдельный процесс или будет использоваться его либа (если таковая имеется)?
2) что на счет интеграции с inkscape?
3) Linux онли, или труЪ кроссплатформ?
4) Цель - скорость обработки?
5) Что на счет svgz?
Пока все.

PS: скоро Qt5 выходит 

[spectator]

Почему бы не присоединиться к inkscape, чтобы исправить те самые недочёты¸о которых вы упомянули.

[andrew_bye]

1) Для Perl'a существует Qt морда - perlqt4 называется. Поэтому вопрос с процессами стоит обсудить и выбрать наиболее оптимальный.

2) Inkscape обрабатывает файлы поштучно, а хотелось бы иметь возможность пакетной обработки. Т.е. все действия пользователя должны свестись к следующей схеме:
- указал Input folder и Output folder;
- при помощи чекбоксов (выпадающих списков и т.д.) или пресетов выбрал необходимые параметры оптимизации;
- нажал на кнопку "Start" и стал заниматься своими делами.
Поэтому особой надобности в интеграции с Inkscape я не вижу.

3) Qt и Perl - кроссплатформенны, так что с учетом примерной схемы работы программы (см. выше), особых проблем в написании кроссплатформенного продукта я не вижу.

4) Цель - создать для конечного пользователя удобный и функциональный инструмент по оптимизации svg-файлов. Т.е. пользователь через удобный графический интерфейс должен сам выбирать, что в svg-файлах оптимизировать, а что нет. Высокая скорость обработки данных конечно же приветствуется, но она не должна идти в ущерб надежности работы программы.

5) svgz - это сжатый gzip'ом svg. Так что обрабатывать соответствующие файлы можно по схеме: разархивация -> обработка -> архивация (по желанию пользователя).

[RazrFalcon]

1)

Sep 19th, 2003

...
2) Ок
3) Ок
4) Ок
5) Ок
 

[andrew_bye]

1)

Sep 19th, 2003

...

Исправил неверную ссылку. Сейчас для perlqt4:

Jun 04, 2011

[RazrFalcon]

Так это вроде биндинг. Не пойму как его совместить потом с обычным кьютом.
Пользователь решил продолжить мысль 21 Июля 2011, 15:53:31:думаю для начала хватит QRegExp и QXml, имхо

[alexander.pronin]

Мне кажется, что надо иметь 2 вещи:
- для работы, проверки валидности и просмотра  svg надо иметь хороший xml редактор (типа Altova XMLSpy)
- просмотр отредактированного файла.
Умение парсить xml файлы любым способом позволит все заавтоматизировать. За основу можно принять и перл, но питон ничем не хуже, а в основном - лучше.

[andrew_bye]

Валидность svg-файлов до настоящего времени я проверял утилитой xmlstarlet:

Код: [Выделить]

xmlstarlet val -q имя_файла.svg
Этой-же утилитой можно исправлять файлы с ошибками (например с отсутствующими закрывающими тэгами):

Код: [Выделить]

xmlstarlet fo -R -Q имя_файла.svg
Отредактированные файлы можно смело смотреть в текстовом редакторе Kate - он подсвечивает xml-синтаксис.

Против питона ничего не имею, просто, как по мне, синтаксис у него уж больно куртуазно-маньерический. ИМХО Перл в этом плане как-то попроще.
Пользователь решил продолжить мысль 21 Июля 2011, 18:59:58:Да, и чуть было не забыл, сейчас в различных дистрибутивах python python'у - рознь! Например, в Ubuntu под python'ом все еще подразумевается его вторая ветка, а в Arch'e - третья.

[hippi90]

А зачем собственно для такого инструмента GUI? Мне кажется, удобнее будет использовать консольную программу, проще добавлять/удалять новые ключи, возможность встраивания в скрипты и т.д.

[RazrFalcon]

Ну гуй тоже нужен. Проще ПКМ по файлу и галочки поставить, чем с консолью возится.
Да и нет проблемы сделать отдельно гуй и cli.

[hippi90]

Тогда может GUI сделать отдельно, а саму программу отдельно? Тогда можно будет и не заморачиваться с GUI на Perl, можно будет на С++/Qt написать.

[RazrFalcon]

Не, гуи не на перле. На перле только парсер. Пока.

[andrew_bye]

Итак, чтобы окончательно определиться с выбором инструментов, исходим из следующих двух постулатов:

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

- Средний размер обрабатываемых файлов будет колебаться от десятков килобайт до нескольких мегабайт (SVG-файлы в несколько десятков мегабайт я еще не встречал).

Поэтому на данный момент возможны два варианта:
1) Все пишется на Qt/С++.
2) На Qt пишется только GUI, а на скриптовом языке (я думаю, что Perl - это сейчас наиболее оптимальный вариант) - сама программа обработки файлов.

По первому варианту пока ничего не могу сказать, поскольку в компилируемых ЯП я пока не очень шарю, хотя существует мнение, что они работают быстрее интерпретируемых ЯП.

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

Вот такие пока мысли по данному поводу.

[RazrFalcon]

Ну тогда полностью все писать на перле.
А уже к готовой программе добавлять ГУИ.

К c++ добавить что либо не сложнее чем к перлу, с той разницей что компилировать еще нужно будет, что не особо долго.
Но тут спор сводится к: интерпретируемый ЯП использовать или нет. А то, в данном случает, просто предпочтения.

На ссях можно и консольную написать. А потом сделать при сборке --no-gui и все.

Ну и никто не мешает оформить прогу не консолью, а либой. Тогда с тем же успехом можно и в других прогах использовать.

О скорости работы пока говорить рано.
Парсер текста, имхо, часами работать не будет. Пару сек макс.