Про формат SVG и Inkscape

nabbla1 — 27.07.2024 Снова "провалился в кроличью нору". Наконец-то вывел и реализовал интерполяцию движения в плоскости при помощи некоммутирующих дуальных комплексных чисел, попутно научился ими пользоваться, причём мне показалось, что под 2D-игры и прочую 2D-графику они весьма интересны. Это одно из самых экономичных представлений произвольного движения, имеет интуитивно понятное умножение "слева" и "справа", и прямо "из коробки" позволяет делать параллакс, когда у нас несколько "плоскостей", которые двигаются с разными скоростями, включая и совсем "задник", который остаётся неизменным.

Накатал текста аж на 45 килобайт, но подумал, что никого это не впечатлит, если примером применения опять станут пресловутые гармошки. Надо демонстрацию покрасивше сделать, и с этой целью решил научиться парсить SVG-файл, не весь целиком, а хотя бы элемент Path. Штука оказалась весьма своеобразной, равно как и его взаимоотношения с Inkscape'ом, да и откуда есть появился Inkscape...

Мой первый успешный парсинг/рендер "корешка" из LaTeX:


Сам по себе SVG (Scalable Vector Graphics) имеет XML синтаксис. Возьмём "корешок", сгенерированный из LaTeX:


Его можно открыть в текстовом редакторе, будет вот такое:

Здесь использовано пять элементов path, описывающих символ корня, икс, игрек, двойку и плюс. Затем двойка использована дважды, а все остальные символы - по одному разу.

Непосредственно описание "пути" содержится в аттрибуте "d", т.е data. Ровно в этом месте авторам вдруг безумно захотелось поэкономить интернет-трафик, и они начали экономить на спичках!

Весь этот "путь" состоит из команд, каждая из которых описана одной-единственной буквой:
- MoveTo, или M: переместить "перо" на новую позицию, ничего при этом не рисуя. Ровно с этой команды начинается каждый путь, чтобы было ясно, откуда начинать вести кривую. Если буква большая, значит координаты абсолютные, если маленькая - то относительные, т.е смещение относительно прошлого положения "пера".
- LineTo, или L: нарисовать прямую линию от текущего положения до указанных координат. То же самое: большая буква - координаты абсолютные, маленькая буква - относительные.
- Horizontal, или H: горизонтальная прямая, поэтому координата нужна всего одна.
- Vertical, или V: вертикальная прямая, та же история.
- CurveTo, хотя я её запомнил как CubicBezier, короче, C: нарисовать кубическую кривую Безье от текущего положения. Первыми передаются координаты первой управляющей точки, затем второй, и под конец - конечная точка кривой,
- Smooth, а я подумал Symmetric, в общем, S: всё та же кривая Безье, но первую управляющую точку не передаём - она расположена зеркально относительно последней управляющей точки, если у нас последней командой тоже был Безье. А если была прямая, то первая управляющая точка совпадает просто с первой точкой, в результате чего кривая в этом месте максимально спрямлённая.
- QuadraticBezier, Q: квадратичная кривая Безье, обходящаяся одной контрольной точкой. Передаём сначала её, потом конечную точку.
- T, вообще не знаю, от чего это аббревиатура, в общем, снова квадратичный Безье, но контрольную точку не передаём - она зеркально отражена, если последним был тоже квадратичный Безье, либо совпадает с первой точкой, что вообще сведёт его к обычной прямой линии между двумя точками, но вот захотелось...
- Arc, A: дуга, т.е кусочек эллипса. Передаются размеры большой и малой оси эллипса, его наклон, два булёвых значения, как именно этот эллипс "пристроить", и конечная точка. Странно, что они эти булёвы значения не включили в оси эллипса, придав им знаки, ну вот захотелось так.
- Zамкнуть, или Z: команда без аргументов. Говорит провести прямую линию от текущего места в начало кривой, и в целом объявить эту кривую замкнутой.

Вроде бы кажется логичным... А потом начинается копеечная экономия. Все ненужные разделители можно убрать! Ввёл команду - сразу пиши число, безо всяких пробелов. Одно число написал, а второе у тебя отрицательное - пиши прям слитно, парсер должен догадаться, что как только посреди первого числа вдруг минус появился, значит это уже следующее число началось! Или если оно положительное, меньше единицы, и десятичная точка в первом числе уже была, пиши это число прям сразу, ведь запись .5 вполне нормальная, и снова парсер сообразит: раз вторая точка, значит, за ней уже следующее число.

Нужно несколько одинаковых команд подряд, например, кубические Безье - напиши C всего один раз, а потом сыпь аргументами до посинения! Отсчитав первые 6 аргументов и увидев следующие, парсер должен понять: значит, пошла ещё одна Безье, и всё это прочитать.

Но с командой M (MoveTo) такой фокус не проходит: если за первыми двумя аргументами последовали ещё и ещё, стандарт призывает интерпретировать все последующие пары как неявную команду L (LineTo), т.к просто двигать точку туда-сюда, ничего не рисуя, бессмысленно.

Я это дело СЛУЧАЙНО поизучал по документации на SVG 2.0, не зная, что он ещё нифига не принят, и, очень вероятно, уже и не будет принят, т.к "всем пофиг". Конкретно для path они предлагали буквально несколько нововведений. Во-первых, команда B (Bearing), которая меняет смысл относительных координат. Если раньше нужно было к текущему X прибавить dX, к текущему Y прибавить dY, то теперь dX по сути означает сдвиг "вперёд", а dY - "влево по ходу движения", ну а направление движения - тот самый Bearing, который по умолчанию нулевой, но можно его задавать. Идея была - сделать что-то вроде "черепашьей графики".

А второе нововведение ещё усложняет парсер, поскольку предлагает воспринимать Z не только как обособленную команду, но и ставить её вместо последней пары координат, например, в кубическом Безье. Это будет означать: конечной точкой этой кривой Безье станет начальная точка всей кривой целиком, и на этом построение завершаем, считая кривую замкнутой.

Мне стало интересно посмотреть, насколько "оптимизированный код" даёт тот же самый Inkscape, для чего я нарисовал в нём дугу и немудрёную кривулину (не через окружность, а через кривые Безье):


и потом открыл файл в текстовом редакторе. Первое, что я увидел - аттрибуты sodipodi повсюду. Вот где описывается дуга:

Мне поначалу казалось, что это какая-то аббревиатура, на манер MISO/MOSI в SPI. В спецификации на SVG ничего подобного не нашёл, но в целом поиск в интернете дал результаты. Оказалось, что Inkscape - это форк от графического редактора Sodipodi, который, в свою очередь форк от редактора Gill, сделанный одним человеком из Эстонии с русской фамилией. В англоязычном интервью он объяснял, что sodipodi - это эстонское слово, означающее мешанину, но лично мне кажется, корректный русский перевод здесь - каляка-маляка.

Ещё тогда внутреннее представление объектов в векторном редакторе не вполне соответствовало представлению в SVG, поэтому, чтобы не потерять данные, вся дополнительная информация и записывалась в эти аттрибуты sodipodi, которые обычные читалки тупо игнорируют. И даже когда sodipodi превратился в Inkscape, представление осталось старым.

А вот моя кривулина:

Прямо в самом начале особенность на особенности сидит! Сначала команда m, с маленькой буквы, т.е относительные координаты, по которым установить начало кривой. Но ведь мы пока не знаем, где у нас "перо" стоит! На это в спецификации есть ответ: начальное положение (0;0) в начале каждого Path, поэтому что m, что M должны вести себя одинаково. А далее, за первой парой координат следует вторая пара координат. Это уже ПРЯМАЯ ЛИНИЯ, причём раз m была с маленькой буквы, значит и здесь кординаты относительные!

С другой стороны, пробелов Inkscape не жалеет, он стоит и после m, и перед "-161", хотя минус позволял бы пробел и не ставить. Так оно всё-таки понятнее. Ещё и X,Y отделяет запятой, а пары отделяет пробелами, хотя с точки зрения формата это вообще одно и то же, просто delimeter и всё тут!

А ещё видим интересную вещь, два нуля в аргументах c (т.е кубический Безье с отн. координатами). Это означает, что первая управляющая точка совпадает с первой точкой. Ровно в этом случае можно было бы поставить s вместо c, и нули эти выкинуть. Но сохраняльщик такой фигнёй не страдает, как минимум, в кривой, нарисованной "от руки". Я попробовал ручками внести такое изменение в файл и снова открыть его в Inkscape: открылся без проблем, показал ровно ту же кривулину, и при последующем сохранении под новым именем даже сохранил эту s вместо c.

Довольно долго соображал, как эту штуку сколько-нибудь "красиво" отпарсить. Мне в конечном итоге надо было получить набор точек, которые затем можно подвергать движению, и набор индексов, по которым из этих точек составляются кривые Безье, для старого доброго GDIшного вызова PolyBezier. Чем хороши Безье - они описываются ИСКЛЮЧИТЕЛЬНО ТОЧКАМИ, т.е все они преобразуются единообразно. С дугами дела хуже, как в SVG, так и в GDI. В SVG есть два "скаляра", вдруг затесавшихся среди векторов: это длины большой и малой оси эллипса. В случае движения они преобразовываться не должны, хотя мы можем захотеть ещё и масштабирование добавить, оно естественным образом в некомм. дуал. компл. число тоже входит, а тогда и эти длины придётся масштабировать! А в GDI, в команде Arc, как будто бы, всё на координатах, только вот незадача - эллипс этот поворачивать нельзя, он просто вписывается в прямоугольник с горизонтальными и вертикальными сторонами. А значит, при произвольном движении (включая вращение) у нас этот эллипс поведёт себя очень нехорошо... В итоге решил пока на дуги забить: позже можно будет их худо-бедно приблизить тем же Безье (может, несколькими), зато не мучаться.

Пришёл к выводу, что непосредственно прочитывая новую буковку (имя команды), мы ничего особо делать и не должны, просто обновить значение CurCmd. А выполняем мы команду в тот момент, когда закончили парсинг очередного числа (наткнувшись на что-то ещё), и обнаружили, что оно уже "лишнее", т.е относится уже к следующей команде, имя которой хранится у нас в CurCmd. Тогда оно получается сколько-нибудь единообразно, но команду Z придётся обработать отдельно! Ибо у неё аргументы отсутствуют, и стоит она чаще всего последней.

Немножко костыльно/велосипедно, зато быстро написалось: после громких раздумий буквально за часик, и довольно компактно (200 строк кода, около 8 КБ), и даже с заделом под SVG 2.0, ну всяко же бывает! Другие "пути" из той формулы:





Что интересно, когда формулы LaTeX преобразуются в SVG, там, пока что, ни разу не встретились ни дуги, ни квадратичные Безье, ни "симметричная версия" (S вместо C) кубических Безье.


Может пригодиться ещё и для лазерных дел, автоматизировать разделку исходных файлов под резку и гравировку, так чтобы он вырезал сначала внутренние отверстия, а только потом деталь с отверстиями из общей фанерки. А ещё "материализовывал клоны" автоматически (LaserGRBL клоны в упор не признаёт!) Сейчас всё это ручками, приятного не очень много, кажется временами, что "лобзиком тупо быстрее"!

Оставить комментарий

Популярные посты:

• Архив