[CDR 2017-2021] Сериализация объектов

  • Автор темы Автор темы Karatau
  • Дата начала Дата начала
конечно, по сравнению с некоторыми другими программами принтмердж используемый напрямую туповат и тугодумен, но я к чему вопросы задавал - ведь есть ещё и FreeForm - залить мастера по типам с рамками, значками и прочими неменяемыми адресами и лишь переменную текстовую часть из экселя слать на мастер номер такой-та ... скорость повышается в разы
 
Ну к примеру на одном листе стопицот этикеток с разным текстом разной длины/ширины и разными значками. Да еще и штрихкоды присутствуют, тоже разные. И как быть?
 
эти стопицсот этикеток можно отсортировать и печатать только один тип - наверняка они нужны не по одной ... точнее скажет только ТС. Текст ведь можно и не в одну строку - поле переменного параграф текста вместо артистик - и есть многострочность - конечно там надо будет непременно проверять
 
У вас как то все волшебно получается. В реальном мире на одном листе печатается толпа разномастных этикеток, часто разных размеров и даже цветности ;)
 
я и не спорю, и как раз пытаюсь уточнить у ТС - как это будет выводиться, насколько это будет толпа и как разнобразна она будет
 
Зачем? Мы сразу предполагаем самый нехороший вариант, когда без макроса не обойтись.
Да лучше и более правильнее и простые варианты макросом делать ибо гибче и результат более управляем.
 
Решена. Это хорошо. Все же спрошу ещё, интереса ради ...
Эта этикетка ( -и) однотипны? Или на большом листе будет сразу несколько типов этикеток разного типа?
Какие данные в приведенном примере постоянны и какие меняются? Что вы подгружаете их экселевского файла?
И ещё ... каким способом это предполагается выводить на печать? Офсет? Оперативка?
Да, компоновка этикеток однотипная. В нее входит заголовок, текст, иногда таблица с составом, код, код страны, вес и значки. Все это приходит в экселовском файле. По упаковке устанавливается размер этикетки, цвета фона и текста. Несколько сотен продуктов и пол-сотни стран, можно посчитать их общее количество. На листе всегда одна этикетка и она отправляется представительству в стране. Как страна ее будет печатать - это их внутреннее дело, главное, чтобы продукт продавался уже с ней. Скрипт по автоматической верстке уже работает 2 года, сокращает время работы над этикеткой с 20 мин. до 2 минут.
 
Без разницы. На самом деле, PrintMerge в кореле - достаточно тупой, бессмысленный и беспощадный инструмент, чтобы макросом удобнее было.
Но смысла закидывания отрисовщика непосредственно в код я так и не разумею. Ну ладно, кривую загнать в код можно (да и то если маленькую и несложную типа лого или значка) Но существует полно объектов, которые так не закодить. Более того - банально удобнее хранить зачки в отдельных файлах. К примеру, поменяли чуть-чуть значок - что, опять перекодировать? А так файл подправил и все.
Да, PrintMerge - это для совсем другого
Загнать в макрос хотелось именно простые штуки типа значков, подправлять их не нужно, это все стандартизировано. И даже наоборот, закрыть от дизайнеров эти значки, чтобы не смогли случайно их изменить.
 
конечно, по сравнению с некоторыми другими программами принтмердж используемый напрямую туповат и тугодумен, но я к чему вопросы задавал - ведь есть ещё и FreeForm - залить мастера по типам с рамками, значками и прочими неменяемыми адресами и лишь переменную текстовую часть из экселя слать на мастер номер такой-та ... скорость повышается в разы
ПринтМердж до того надоел, что был написан собственный скрипт, простой и понятный... И более гибкий. Работаю теперь только с ним и Мердж вспоминаю, как страшный сон %8
 
И даже наоборот, закрыть от дизайнеров эти значки, чтобы не смогли случайно их изменить.
К бинарнику макроса в конец дописать гораздо проще было бы. Я полагаю, что даже по скорости рисовать достаточно сложный векторный объект "по точкам" из макроса медленнее, чем импортировать готовый, поэтому резона не вижу ни малейшего.
Не говоря уже о том, что чисто эстетически загромождает код.
 
К бинарнику макроса в конец дописать гораздо проще было бы. Я полагаю, что даже по скорости рисовать достаточно сложный векторный объект "по точкам" из макроса медленнее, чем импортировать готовый, поэтому резона не вижу ни малейшего.
Не говоря уже о том, что чисто эстетически загромождает код.
Засуну все значки в отдельный класс и буду вызывать их оттуда функциями и заглядывать туда больше не буду, так что код будет чистый.
Мне кажется, что отрисовка значка средствами VBA будет происходить быстрее, чем импорт файла с ними. Хотя... И то и другое будет происходить за доли секунды, что делает выигрыш несущественным
 
Мне кажется, что отрисовка значка средствами VBA будет происходить быстрее
На несложных объектах - да. Начиная с определенного (достаточно большого) количества узлов и субпутей - медленнее.
Но! действительно, на несложных объектах выигрыш будет в миллисекунды