noobie-iv
commented
7 months ago Разносить выделение и его свойства на два разных этапа - это усложнение работы. Неудобно будет переключаться туда-сюда, чтобы посмотреть, какую рамку я сейчас настраиваю. Надо тыкать в рамку, и сразу видеть ее свойства. По мне логично нарисовать контур, и сразу ему прописать "это картинка, тут просто уровнями jpeg-шум обрезаем", а в этой рамке "дополнительно палитру назначаем с принудительным белым фоном".
А вообще, прежде чем пришивать внешние программы, мне надо сначала тумбочки починить. Они сейчас и в STD не работают, и в STEX через раз. Весь прикол в том, что картинки опознаются по ImageId, который просто содержит путь до исходного файла и номер страницы. Этот Id при обработке передается по цепочке через все фильтры. В исходном ST это оптимизация: все фильтры меняют только матрицу преобразований и контур подрезки, кроме последней output-стадии. Даже имена файлов для кеширования картинок вычисляются на основе пути к файлу. А после развертки надо, чтобы у той же исходной картинки превьюшка поменялась. Значит, надо менять Id и логику его обработки по всей программе - и в фильтрах, и в видах, и в кешах. С основным изображением сработала грубая подмена - на стадии Deskew я генерирую изображение развертки и передаю его в следующий фильтр. А с тумбочками этот трюк не помогает: они грузятся не из фильтра, а независимо по начальному Id, и после подмены они уже не подгружается правильно.
В STEX эта проблема через костыль решена: вместо матрицы преобразований создан собственный класс трансформации, который для случая развертки по запросу умеет вернуть изображение; для этого в нем и все настройки развертки хранить приходится. То есть как бы и старая логика с передачей Id сохранена, и новая логика-подменка срабатывает когда надо. От этого код основных видов и тумбочек STEX уже несовместим с STU/STD; если я и его начну копипастить, это будет уже откат к ветке STEX. Плюс у STEX где-то в цепочках вызовов для обновления тумбочек что-то зевнуто, и тумбочки через раз не обновляются.
А мне надо будет еще и вызов внешних программ в цепочку вставить. Например, вызов фотошопа и ручную правку с заморозкой результата. Для этого нужно ему файл страницы передать, и сохраненный результат где-то в кеш положить, чтобы дальше по цепочке фильтров уже его передавать, а не исходное изображение. Тут копипаста логики из STEX уже не поможет, и логика STU/STA не подойдет. А я пока даже через отладчик все цепочки обновления превью отследить не смог, я же ни под Qt не писал, ни многопоточных программ не отлаживал. Начальная копипаста шла сильно быстрее, чем я рассчитывал, а теперь разбираться в логике получается сильно дольше, чем сначала казалось. Плюс у меня свободное время вышло. Как бы не пришлось теперь отложить релиз до пенсии.
zvezdochiot
Приветствую @noobie-iv .
Я понял решение вашей концепции в рамках струтуры ST:
Для реализации нужного вам, необходим ещё один этап между "Page Layout" и "Output": "Block". Примитивнейший этап, решающий постановку задачи. По умолчанию включает только нулевой блок (то бишь всё). Поверх него плодишь другие блоки (просто блоки, без всяких свойств) ровно таким же образом, как зоны в "Picture Zones" или "Fill Zones". А вот на этапе "Output" прописывается динамический селектор "Block". И в зависимости от выбранного блока формируется маска путём вычитания из маски текущего блока масок всех последующих. Параметры же будут относиться (применяться по вычтенной маске блока и прописываться в xml) не к этапу "Output", а к текущему блоку.
Да это потребует перетрубации "Output": внедрение как самих блоков, так и масок на их основе. Но это решение полностью укладывается в концепцию ST и достигает ваших целей. И не совсем ясно, как копировать свойства между страницами, но это решаемо.
См. также:
5
6