А, всё, понял. Нет, с этим как раз затык. Дело в том, что Width Points - это самостоятельные точки, образующие в итоге так называемый профиль, никак не связанные с точками кривой, и могут быть, соответственно, в любом месте отрезка. Это раз.
Скрипты никак эти данные не получают, во всяком случае официальный скрипт референс Люстры никак их не описывает, ни в новых, ни в старых редакциях. Так что мы не можем передавать/получать их с помощью скриптов.
Однако, любопытство заставило провести меня небольшой эксперимент, в результате которого я пришёл к такому полу-извращенческому лайфхаку. Я расскажу, а ты уже смотри сам, на сколько это "совместимо в жизнью" в твоём случае:
- Люстра позволяет сохранять Width Points данные как профили. Все эти профили последовательно записываются в файл VariableWidthProfiles, с данными в шестандцатиричном формате.
- Из этих данных, декодировав, можно получить название профиля, и относительные координаты Width Points на кривой (0-1), и относительные размеры ширины к величине толщины кривой.
- Затем можно последовательно резать кривую на сегменты и замерять длину между точками, 0-1, 1-2, 2-3, т .д., из этих данных и общей длинны кривой высчитать относительные координаты каждой точки на кривой.
- Затем округилить эти данные, и данные из декодированного VariableWidthProfiles, так можно будет сопоставить точки кривой и Width Point, при условии, конечно, что Width Point был там расположен с небольшой погрешностью, и их количество в принципе совпадает с количеством точек кривой, что, к сожалению, может быть и не так, ибо человеческий фактор + возможные глюки. Во всяком случае, по своему опыту работы с Width Point, нет-нет, да какая-нибудь хрен и приключится.
- И уже в итоге расчитать толщину исходя из толщины кривой, например:
мы знаем, что толщина кривой 18.993 пункта, из шестнадцатиричных данных мы извлекли значение второй Width Point 0.345538432982929. 18.993*0.345538432982929=6.56281145764477 пунктов ширина второй Width Point.
Естественно, я ещё ничего не писал под этом, просто проверил сохраняемость и зависимость этих данных, чтобы понять как они взаимодействуют.
И тут прикол в том, что автоматизировать можно только вычисления, так как если мы даже напишем парсер файла
VariableWidthProfiles, и будем выгружать из него список
, мы не сможем прочитать какой профиль к какой кривой сопоставлен, скрипты эту мету не видят. Тут можно, конечно, назначать каждому PathItem имя, сопоставимое с именем профиля.
Тогда сценарий будет таким:
- Именуем все PathItem, можно заскриптовать, например будет: CustomProfile_1, CustomProfile_2, ...
- Потом, уже вручную, сохраняем профиль каждой с тем же именем.
- Пишем парсер файла VariableWidthProfiles, который на выходе даст нам файла вида:
profileName, widthPointsArray, widthPointsWidthArray
- Пишем парсер для документа, который на выходе даст:
pathName, relativePointsPositionAlongCurveArray, strokeWidth, xPointsPositionArray, yPointsPositionArray
- И в него же, сразу, чтобы два раза не вставать (хотя по идее, можно и парсер файла VariableWidthProfiles записать туда же, в начало, просто выполняться будет дольше), дописываем функцию, которая берёт распарcенные данные из VariableWidthProfiles и для каждой точки в массиве, соответсвующему имени профиля, ищет и вычисляет значение ширины.
Так что, по сути, три скрипта получается, ибо один сбор данных невозможен технически + ручная подготовительная работа с документом, которая, в зависимости от объёма может быть внушительной, и нет никакой страховки от ошибок в данном случае.
Довольно геморройно, и в плане разработки, и в плане применения. На мой вкус, я бы замутил что-то подобное с данными, которые мы всё-таки можем получать, например, координаты и радиус кругов. Но, не знаю, на сколько такой подход впишется в твой сценарий.
З.Ы. Извиняюсь за словоблудие, просто закрепил придуманное описанием. Да и идея не тривиальная, возможно кого-нибудь из форумчан вдохновит на что-то) Ну, и в целом, даёт понимание, что такое Width Points, потому что, вот как Вы, например, ошибочно полагали, что там прямая связь с точками кривой.
З.Ы.Ы. Чего-то я тупанул, и шаг с высчитыванием относительных координат можно опустить, т.к. они идут последовательно, и при условии, что количество точек совпадает, этого делать не нужно. Ну оставлю всё-равно в тексте, потому что это уже такая брутальность, когда нам нужно было бы не просто найти точку, но и удостоверится, что она именно в той части отрезка, где мы ожидаем, что она должна быть. Как дополнительный уровень валидации - норм.
