LINUX.ORG.RU

svgcleaner 0.7.0

 ,


1

4

Вышла новая версия программы для очистки SVG-файлов от лишней информации.

svgcleaner позиционируется как оптимизатор без потерь, строго следующий спецификации SVG 1.1 Full.

Основные изменения:

  • ядро (консольная версия) переписано с C++ на Rust;
  • реализованы собственные библиотеки для разбора SVG и представления SVG в виде DOM;
  • программа стала работать приблизительно в 3 раза быстрее;
  • все функции очистки теперь работают в режиме lossless;
  • степень очистки упала примерно на 5% ради стабильности и корректности;
  • добавлена документация для каждой опции очистки;
  • графический интерфейс переписан с нуля и вынесен в отдельный репозиторий.

Программа распространяется под лицензией GNU GPL v2. Сопутствующие библиотеки — под MPL v2.

Готовые сборки

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: sudopacman (всего исправлений: 6)

Ответ на: комментарий от robus

Компилятор же для него весит около 450 Мб.

pkg info -s rust
rust-1.12.0                    258MiB

И это уже с доками на 70мб. Тут кутя с доками идет в отрыв. А уж если дейстительно часто собираешь сам, то на фоне разных бустов, llvm-ов, гцц разных версий и кутей — вполне приемлимо, ящитаю.

anonymous
()
Ответ на: комментарий от anonymous

Нода всегда и была консольной, глупенький.

boo32
()
Ответ на: комментарий от SkyMaverick

Попробуйте запустить этот 7za: https://dl.dropboxusercontent.com/u/16019144/7za

Не должен выдавать ошибки. Если всё ок - то буду его распространять.

PS: никаких руткитов там нет, если вы не параноик, просто пересобрал с -mtune=generic.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Падает.
Исследовал немного, падает из-за того, что CPU AVX не поддерживает. Падает на инструкции vzeroupper. ЕМНИП в gcc -mno-avx это отключает. По крайней мере, в p7zip, видимо, собрано без AVX-оптимизации.

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

Магия. Уже всё поотключал, а толку 0.

buddhist собираю с -march=core2 -static -mno-sse3 -mno-ssse3, а в objdump всё равно лежат sse3 инструкции. Не в курсе в чём прикол?

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от buddhist

Пробовал generic, как вы и советовали, - тоже самое. Или p7zip сам использует sse, или я хз. Как минимум с -mno-sse2 он собираться отказался.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Нет, ибо lossless.

Это типо религия такая? Как например чистота ФП. Почему нельзя оставить разъём под lossy плагины для практических нужд (в расте наверно проблемы с динамической загрузкой плагинов, да)? Групповые трансформации кстати - отдельное поле для возможных оптимизаций. И почему нельзя применить трансформацию к самим координатам (ну может быть частично в случае если там квадрат вращается например) и округлять уже в правильном масштабе. Да и вообще округление нужно для фигур, нарисованных руками, там маловероятно встретить скалирование в 1000 раз. Так что можно просто проверить матрицу трансформации, уместно ли округление тут.

q0tw4 ★★★★
()
Ответ на: комментарий от RazrFalcon

Минимальный набор инструкций для 64-битного x86 дает arch=athlon64, но проц по ссылке SkyMaverick поддерживает все вплоть до SSE4.2. Но в вашем бинаре есть AVX инструкции в том числе.

buddhist ★★★★★
()
Последнее исправление: buddhist (всего исправлений: 1)
Ответ на: комментарий от q0tw4

Сегодня одно, завтра другое, послезавтра комбайн.

Групповые трансформации кстати

Что вы под этим подразумеваете?

округлять уже в правильном масштабе

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

округление нужно для фигур

У меня на тестах, при точности в 2-3 знака, половина файлов убивается. Даже не стал разбираться.

Так что можно просто проверить матрицу трансформации, уместно ли округление тут.

Поэтому там и сказано, что как только разберусь как это сделать без потерь - сделаю. Сейчас это не реализовано.

RazrFalcon ★★★★★
() автор топика
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

-march=core2 и -mno-sse3 — противоречащие друг другу настройки и, ЕМНИП, arch всегда приоритетнее. Мне кажется, что с бинарем, собранным с -march=core2, у SkyMaverick проблем быть не должно

buddhist ★★★★★
()
Ответ на: комментарий от SkyMaverick

RazrFalcon

Странно, там до сих пор остались AVX-инструкции. Вечером доберусь до убогой тачки с линуксом (древний атом), попробую собрать.

buddhist ★★★★★
()
Ответ на: комментарий от RazrFalcon

Групповые трансформации

Ну короче собирать подобные трансформы элементов в трансформ группы из этих элементов добиваясь более короткой записи трансформов ну или даже более коротких записей координат (ну типа вынести сдвиг на 0.0001 из кучи чисел вида <x>.0001 «за скобки»).

q0tw4 ★★★★
()

А да, упрощение путей оно умеет? Конечно в общем случае надо бы lossy упрощение но хотя бы в случаях когда 2 соседних примитива можно математически точно слить в один.

q0tw4 ★★★★
()
Ответ на: комментарий от DarkEld3r

Ну с ансейфами каждый дурак сможет. А как подгрузить сразу реализацию растового трейта чи как там в расте наследник класса сделан?

q0tw4 ★★★★
()
Ответ на: комментарий от q0tw4

А как подгрузить сразу реализацию растового трейта чи как там в расте наследник класса сделан?

Дык, что помешает возвращать из библиотеки указатель на трейт? Но unsafe всё равно останется.

DarkEld3r ★★★★★
()
Ответ на: комментарий от buddhist

«Урррааа заработало» (с) скрин

Если вы, конечно, доверяете бинарю от рандомного лоровца

Ну я не параноик :) К тому же для благого дела.
ЗЫ. А в чём была загвоздка со сборкой, если не секрет?

SkyMaverick ★★★★★
()
Ответ на: комментарий от DarkEld3r

Дык, что помешает возвращать из библиотеки указатель на трейт?

Хм, а разная версия компилятора не помешает? И вообще оно сможет кастануть из void*? А то помню в кристале были реальные проблемы с тем, чтоб кастануть полиморфный указатель в void* и потом обратно - указатель терял динамический тип и вызывал методы базового класса. Собственно в расте вроде как тоже закос в мономорфность, так что могут быть проблемы. Ну если вместо таблицы вирт функций, встроенной в сам объект используется отдельный указатель на нее, автоматически подставляемый компилятором, но никак не сохраняющийся при касте объекта в void*.

q0tw4 ★★★★
()
Последнее исправление: q0tw4 (всего исправлений: 2)
Ответ на: комментарий от q0tw4

Понял. Такого нет. Обычно это будет длиннее чем координаты:

100 100 100 100 100 100 100 100
0 0 0 0 0 0 0 0 transform="translate(100 100)"

Намного проще как раз применять трансформации, а не выносить. Но частичный «вынос» тоже будет.

RazrFalcon ★★★★★
() автор топика
Последнее исправление: RazrFalcon (всего исправлений: 2)

https://github.com/RazrFalcon/svgcleaner#alternatives как-то очень поверхностно сравнивается.

И там какие-то стрёмные заявления про беспотерьность. Если про то, что нет фичи округления точности коодинат - это какое-то сомнительное преимущество. И если ничего не путаю, то SVGO по дефолту оптимизирует без потерь.

В goals тоже слегка абстрактно, «дальше, выше, сильнее». Ни о чем.

Я ничего против проекта не имею. Просто с точки зрения человека, который пользовался SVGO, не совсем понятно нафик это надо. Возможно есть какие-то интересности, но они не донесены.

Vit ★★★★★
()
Ответ на: комментарий от Vit

А, нашел графики. Довольно симпатично получается.

Могу еще преложить тесты отсюда https://github.com/fontello/svgpath/tree/master/test глянуть. Приходилось со всякими косяками сталкиваться на трансформациях арок и т.п. В SVGO кстати у арок есть проблемы.

Vit ★★★★★
()
Ответ на: комментарий от Vit

не совсем понятно нафик это надо

График Correctness ни о чём не говорит? svgo ни разу не lossless. Плюс у него много ошибок.

И там какие-то стрёмные заявления про беспотерьность

Что там не понятно?

И если ничего не путаю, то SVGO по дефолту оптимизирует без потерь.

Нет.

В goals тоже слегка абстрактно, «дальше, выше, сильнее». Ни о чем.

Предложите лучше.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от Vit

https://github.com/fontello/svgpath/tree/master/test

Не вижу там svg файлов. Выдирать тесты из api.js муторно, и там не совсем то, что делает прога. С парсингом путей у меня проблем нет.

У меня еще осталось 3000 файлов-тестов от вебкита. Вот там настоящий ад.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Библиотека делалась для фонтов, а не для картинок. Там тесты афинных преобразований над сегментами пути. Если вы трансформации на контуры не накладываете, тогда не нужно.

Vit ★★★★★
()
Ответ на: комментарий от RazrFalcon

Что там не понятно?

Слова там понятны, но не очень понятно зачем это надо юзеру. Например, округление координат до целых довольно прилично сокращает размер (точка + как минимум еще 1 знак после). Какой смысл лишать юзера подобной возможности если он знает что делает? Если картинки 1000х1000, там целых обычно достаточно.

Про скорость - круто конечно. Но мне трудно представить проекты, где надо тонны картинок постоянно оптимизировать.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Например, округление координат до целых довольно прилично сокращает размер

Нет. Сейчас используется округление до 8 знаков после запятой. Уменьшение до 6 даёт прирос от силы в пол процента. До 3 - пару процентов, при условии, что половину файлов корежит. У меня даже с точностью в 8 знаков куча артефактов, а вы про 1 знак после запятой. Не смешите.

Но мне трудно представить проекты, где надо тонны картинок постоянно оптимизировать.

Паки иконок? Тем более разница почти в 100 раз - это не шутки. Мне интересно выжать макс. производительность. Вам не нужно - проходите мимо.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от Vit

он знает что делает

Обычно не знает. Если так хочется - пусть руками чистит. Производительно то всё равно не важна вам.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Не смешите.

Рад что вас повеселил. Это однако не меняет факта, что на монохромных картинках, состоящих только из path, разница в размерах гораздо больше, чем вы говорите.

Паки иконок? Тем более разница почти в 100 раз - это не шутки. Мне интересно выжать макс. производительность. Вам не нужно - проходите мимо.

Хосспадя... примите разупорин уже. Вы спросили, что именно непонятно. Я просто ответил на ваш вопрос.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Это однако не меняет факта, что на монохромных картинках, состоящих только из path, разница в размерах гораздо больше, чем вы говорите.

В FAQ чётко указано, что как только я найду способ как статически доказать неизменность изображения - я добавлю эту фичу.

Хосспадя... примите разупорин уже.

Наезжаете на мой проект даже не дочитав ридми, а я потом еще и крайний.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

В FAQ чётко указано, что как только я найду способ как статически доказать неизменность изображения - я добавлю эту фичу.

Подразумевается вычисление погрешности с учетом трансформаций? Изображение не может остаться совсем неизменным после округления. Другое дело, что 0.1% обычно мало кого волнует.

Можно даже картинку 10х10 менять на 1000х1000 + scale(0.01), чтобы от плавучки в остальных местах избавиться.

Vit ★★★★★
()

вспомнил сисиклинер, пкклинер и прочий подобный шлак. вздрогнул )

dk-
()
Ответ на: комментарий от Vit

Любое округление. Там лишь пример.

К примеру: имеем длину в 0.001in, при определенных dpi это будет не таким уж маленьким значением.

Так же есть куча проблем с путями. К примеру задание окружности через один ArcTo путём расположения двух координат очень близко друг к другу, но не совпадающих. Малейшее округление, даже до 5-6 знаков, приведёт к совпадению координат и пропаже окружностей. В старой версии даже был костыль, который пропускал округление ArcTo.

Малейшее округление stdDeviation приводит к искажению размытия. Даже текущих 8-и знаков после запятой не хватает.

И я могу продолжать бесконечно.

Повторюсь: если округление и будет реализовано, то не глобальное, а отдельное для разных видов значений.

RazrFalcon ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Ну естественно надо округлять не всё под одну гребенку. У тех же арок с радиусами надо обходиться аккуратнее. А так на фонтелле пути постоянно округляются, и с проблемами никто не прибегает.

Vit ★★★★★
()
Ответ на: комментарий от Vit

Ну так вот такого округления пока нет. На шрифта может не так заметно. Когда у нас путь рендерится на холст 1000х1000 - разница может быть ощутимая.

Вот пример проблемы: https://github.com/RazrFalcon/svgcleaner/blob/master/docs/testing_notes.rst#a...

RazrFalcon ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.