Меня да.
"О чём ты?" — недоумевающе спросите Вы.
Вы когда-нибудь работали с svg? Я имею ввиду: вы когда нибудь создавали svg изображения кодом? а не эти ваши там фигмы иллюстраторы и прочие чудеса света.
Если да — то вы вероятно понимаете, как трудно изменять размер svg.
И я говорю не про относительный viewbox с моделями представления контента по типу preserveAspectRatio и подобных чудес жизни. Я говорю про то, чтобы взять уже имеющуюся svg картинку и увеличить её в 2 или, например, в 3 раза.
Моя идея проста как рисунок дикаря: "А что если просто взять все значения и изменить их на какой-то коэффициент (скажем умножить все цифорки что есть в файле на 2)? Получим ли мы желаемый результат?"
Вынашивал я эту мысль довольно долго. В интернете ответ найти не смог, что странно (хотя может я просто плохо искал).
Поэтому решился на эксперимент!
И с целью его проведения было создано это cli приложение.
Да в интернете навалом различных инструментов, которые способны привести svg к нужному размеру.
Вот например один из тех которыми я постоянно пользуюсь: iloveimg.
Но все они как один подменяют мою прекрасную разметку на какие-то грязные path-ы, на которые даже страшно взглянуть.
Я понимаю, что моя реализация далека от идеала: давайте хотя бы подумаем о том, что в файле могут находиться значения которые мы вот ну никак не желаем менять (например SMIL анимации) или что, например, делать со стилями в блоке < style> расположившимися прямо внутри нашего <svg>? Просто игнорировать? А если они переопределяют размеры, которые мы как бы то ни было должны скейлить? Получается и за этим тоже следует следить?
Нет, это всё действительно сложно.
Но давайте не забывать, что это всего лишь эксперимент...
И мы рассмотрим лишь самый базовый случай, чтобы узнать верна ли моя странная теория или нет.
Идея с самого начала была амбициозной. Я понимал, что ей не суждено сбыться.
После первого же теста я понял, что в документе оказывается гораздо больше чисел которые нельзя трогать при скейле. Среди них: namespace, различные цвета (заливки, обводки, градиенты), значение ширины обводки и прочие приколы...
Какой-то результат я всё-таки получил! Что, конечно, не может не радовать. Пришлось вручную подправить namespace, картинка потеряла свои цвета, но приобрела нужные пропорции!!!
Теория всё-таки оказалась верна, осталось лишь довести её до ума...
И прописать все ignore-кейсы...
Но это как-нибудь в другой раз...
А пока что можете посмотреть на моего бедного экспериментуемого
Знакомьтесь, это SiWi:
И ко мне на эксперимент он пришел вот в таком виде:
Размеры 100x100 если что
После первого "сырого" теста он приобрел нужные размеры, но стал выглядеть вот так:
Тут размеры уже 200x200
Смотрится конечно грустно, но это всё во благо науки (я надеюсь)
На вход cli принимает путь до файла и коэффициент. Программа изменяет все численные значения в файле на указанный коэффициент и возвращает новый файл с измененными значениями.
- Клонируем репозиторий
git clone https://github.com/daniilboyarinkov/scale-svg.git- Устанавливаем зависимости
npm installnpm link- Тестируем!-
scale-svg scale <ваш чудесный файл>-c, --coefficient — коэффициент изменения (любое численное значение)
-o, --output — кастомный путь куда будет записан результат
scale-svg scale input.svg -c 2 -o output.svgили:
scale-svg scale input.svg --coefficient 1.1 --output output.svgЯ переписал логику скейла (всё-таки). Прямое изменение всех чисел что найдутся в файле в лоб я заменил перебором необходимых svg тегов и их аттрибутов. Это сделано чтобы скейлить только размерозависимые величины и не трогать цвета и прочие аттрибуты числа в которых трогать не следует.
Да.
Я был прав. Рад, что убедился в этом.
В целом, тестов было немного, и работает относительно стабильно.
Но не всё гладко. Очевидно. Например, при больших коэффициентах, если в вашей svg есть встроенные SMIL анимации, то они начинают вести себя странно. В целом, анимации это никогда не просто. Возможно и это я когда-нибудь исправлю. Но пока что так...
Результат вышел примерно следующий:
До скейла:
После:
(масштаб примерно одинаковый, анимации сохранены)