Очередная статья на тему JDF? Да, но в этот раз технологию мы будем рассматривать «изнутри», обратившись к языку формата — XML. Для этого изучим реальные примеры JDF-автоматизации для решений Kodak, Harlequin, Agfa и пр.
А жив ли JDF? Несомненно, что подтверждает слепое тестирование IPA и сквозная автоматизация систем на Drupa-2008. Впрочем, от совершенства реальная картина далека. Вскрытие некоторых JDF-файлов покажет образцы неудачных кодов. Начнём с основ: формат JDF позволяет машинам разговаривать между собой. «Беседы», заключающие в себе параметры работ, называют «взаимодействием».
В основе JDF-формата лежит язык описания XML (eXtensible Markup Language, расширяемый язык разметки), напоминающий хорошо известный по веб-страницам язык гипертекстовой разметки HTML (Hypertext Markup Language). Языки разметки просты и легко читаемы, состоят из открывающих и закрывающих тегов (управляющих кодов), между которыми и хранится информация. Фраза на языке HTML
<i>Hello Friend</i>
будет отображена браузером на веб-странице как Hello Friend.
У каждой индустрии свой список тегов XMLtags. Файлы XML есть в ОС Windows и Mac, в протоколах мобильных телефонов, на фондовых биржах. Свой JDF-формат есть даже у музыкантов — Music Markup Language (MML). По сути, JDF — список имён XML-тегов, которые решено использовать в полиграфической отрасли.
Вот строки XML-кода из реального JDF-файла:
<RunList Run=”1” Pages=”0~7” NPage=”8”><LayoutElement ElementType=”Document”>
<FileSpec URL=”Source%20Documents/Ford Brochure.pdf” MimeType=”application/pdf”/>
</LayoutElement>
</RunList>
Фрагмент XML-кода содержит тег RunList с соответствующим ему закрывающим тегом /RunList. Точно также есть открывающий и закрывающий LayoutElement. В XML-файлах имена тегов могут быть любыми, но для корректного взаимодействия между оборудованием отвечающая за JDF-стандарты организация CIP4.org выпустила спецификации с точными именами тегов для каждой ситуации. Создающее JDF-файл приложение не должно пользоваться формулировками run list, Run List, job list, page list и пр. Единственно возможный вариант описания списка тиражей — RunList. Такая стабильность поддерживает совместимость различной техники.
Читать JDF легко. Представленный выше код XML/JDF содержит инструкции для 8-страничного макета, источником выступают страницы 0-7 из файла FordBrochure.pdf.
Как видим, JDF/XML не слишком отличается от текстовых файлов — код намеренно сделали удобным для чтения и понимания.
Проблемы «частных» тегов
Чтобы JDF-формат работал, JDF-файл изучать необязательно — основной части пользователей никогда не приходилось читать XML-код. Но есть ситуации, когда полезно приглядеться к нему внимательнее. Недавно я загрузил с сайта kodak.com инструмент для планирования спуска полос Kodak Preps 5.3.1, после чего вывел спуск, экспортировав задание как JDF-файл заказа. В файле JDF/XML я обнаружил следующую строку:
<ScreenSelector Angle=”105” SSi:MFGAngle=”105”Frequency=”150” SSi:MFGFrequency=”150” Separation=”Cyan”/>
В файле с информацией по растрированию голубой печатной формы теги дублируются. Угол наклона 105° указан и для официального JDF-элемента Angle, и для «частного» тега SSi:MFAngle. Дважды присутствует линиатура растра в 150 lpi — в официальном теге Frequency и в частном SSi:MFGFrequency.
Почему подобный синтаксис чреват проблемами? Для начала замечу, что не все производственные ситуации в полиграфии охвачены тегами, поэтому «частные» варианты позволительны. Они используются там, где отсутствует JDF-спецификация по какой-либо специализированной причудливой функции, присутствующей у конкретного поставщика. Угол наклона растра и линиатура таковыми не являются — частные теги при наличии официальных терминов неприемлемы. Поскольку Preps первой из программ для спуска полос получала сертификат JDF, эти моменты остались без внимания. Но в перспективе их стоит учитывать — это снимет необходимость в тестировании пар уже прошедших JDF-сертификацию систем для пресловутой «интеграции».
Одна из причин путаницы вокруг JDF — поток пресс-релизов следующего типа: «завершена и доступна JDF-интеграция между допечатными системами X и Y». Но зачем нужна «интеграция», если оба поставщика работают с JDF? Индустрия давно имеет дело с готовящимися по чётким спецификациям допечатными файлами, например, с PDF и TIFF стандартов Adobe, стандартизированными ICC-профилями и файлами JPEG. Представляете, что начнётся, если устраивать «интеграцию» при отправке каждого такого файла? Не нужно оценивать ICC-профиль от X-Rite ProfileMaker, чтобы открыть и использовать его через ColorBurst RIP. Что уж говорить о задающих тон техпроцессах на базе PDF.
Файлы заданий JDF тоже создаются по спецификациям, в данном случае это JDF Specification (текущая версия 1.3). В процессе сертификации JDF содержимое файла проверяется по Спецификациям на соответствие требованиям интеграции ICS (Interoperability Conformance Specification). Проверка гарантирует, что решение выдаёт корректные, верно сформулированные JDF-файлы и может применяться для свободного обмена информацией между системами.
Выходит, что проверенный на корректность файл должен свободно передаваться между любыми системами с поддержкой JDF. Похоже, этот момент ускользает от поставщиков, с завидным упорством продолжающих попытки «интеграции», добиваясь передачи данных между системами посредством JDF-файлов. Все эти усилия сводят на нет смысл открытых стандартов.
JDF прекрасно работает и без предварительной «интеграции». На открытом тестировании JDF-решений во время технической конференции IPA в Чикаго (июнь прошлого года) подготовленный сертифицированной системой корректный JDF-файл выложили на FTP-сайт — для любого желающего принять участие поставщика. В нём содержались инструкции по выполнению спуска полос из исходного PDF-файла. Самого спуска участники не видели — все инструкции предлагалось получить посредством JDF.
Спуск был подготовлен ПО Dynagram DynaStrip. Приятно отметить, что файл автоматически обработали системы Agfa :ApogeeX, EskoArtwork Odystar, Beijing Founder EagleProof, CGS ColorTuner TrueFlow, DALiM Mistral Printempo, Heidelberg PrintReady, Heidelberg MetaDimension и Rampage, доказав отсутствие необходимости в т. н. «интеграции». Тест подчеркнул широкие возможности JDF — обработка и создание спуска полос выполнялись через горячие папки в рамках автоматизированных техпроцессов, без участия пользователей и ошибок с их стороны. Именно так может и должен работать JDF-формат.
Drupa-2004 по общему мнению стала «JDF-выставкой», на которой формат анонсировали и представляли все подряд. Через четыре года 22 поставщика в зале 7 образовали отдельную экспозицию JDF Experience Parc. Каждый предлагал ряд демонстраций — впервые такое количество и разнообразие JDF-операций показали широкой публике.
Экспозиция развеяла все мифы вокруг автоматизации с JDF — она реальна и действует. Поставщики автоматизированных систем и ПО с поддержкой JDF представили их работу на примере реальных заказов. Часть презентаций охватывала полный техпроцесс: регистрация заказа в АСУП, передача в ПО для вёрстки, на спуск полос и, наконец, на RIP или эмуляцию печатной машины. Распространённый сценарий: АСУП — допечатная подготовка с участием т. н. заполнителей (gray boxes), например, от EFI Hagen на Heidelberg Prinect Prepress Manager или от АСУП Intraprint на DALiM. Gray boxes — JDF-эквивалент «заполнителей», подставляемые на место временно отсутствующей информации. JDF-файл содержит доступную информацию, заполнитель — ту, которая должна поступить.
Вернувшись с Drupa, я продолжил опыты с JDF на примере Dynastrip от изобретателя из Квебека Франсуа Жерара и его директора по исследованиям и разработкам Шанте Лемея. Созданный DynaStrip JDF-файл обрабатывался двумя приложениями — Agfa :ApogeeX и Global Graphics Harlequin RIP.
На рисунке (с. 23) представлены реальные диалоговые окна программ в процессе эксперимента. ПО Dynagram DynaStrip 5.2 создавало спуск полос с наполнением, контрольными шкалами и обрезными метками, экспортируя макет как JDF-файл. В :ApogeeX формировался элементарный автоматизированный техпроцесс — перетаскиванием шести формирующих технологический поток пиктограмм.
В техпроцесс JDF-файл попадал через горячую папку. Приняв его, :ApogeeX размещала файлы с наполнением и воссоздавала готовый к выводу на цветопробное устройство или печатные формы спуск полос. Та же процедура выполнялась на Harlequin RIP. Процесс наглядно подтвердил работоспособность JDF — технология в состоянии автоматизировать техпроцесс, сведя до минимума участие оператора, увеличив эффективность и уменьшив риск ошибок.
Понять, какие системы будут взаимодействовать друг с другом, можно по матрице интеграции CIP4/JDF (cip4.org/matrix) — таблице с перечислением пар установленных или разработанных систем разных производителей. Решения разбиты по категориям: АСУП, допечать, цифровая печать, производственное планирование. Варианты уровня интеграции — в процессе, доступна, инсталляции, подтверждена заказчиком. Последний (Customer Confirmed) — самый надёжный и означает, что специалисты CIP4 напрямую связались с типографией, чтобы удостовериться в функциональности системы и в том, как она зарекомендовала себя в повседневной практике. Всего в матрице 363 рабочие пары разного уровня интеграции — хорошая иллюстрация прогресса и распространения JDF-технологий. Особый интерес представляют собой одобренные клиентами пары, отображающие реальное взаимодействие систем на печатном производстве.
Одна из компаний с большим количеством подтверждений от клиентов — Hiflex с собственной АСУП. По информации разработчика, только его система основана на истинной JDF-структуре данных, хотя сертификаты JDF-взаимодействия от занимающейся этим процессом для CIP4 ассоциации PIA/GATF получили EFI и Hiflex.
Один из основных способов автоматизации предприятия — подключение через JDF допечатных систем к АСУП. Клиенты Hiflex используют для этого АСУП Hiflex и Kodak Prinergy (опциональный модуль Business Link). JDF-протоколы служат не только для передачи информации от АСУП на допечатные системы, но и для обратной связи. По окончании вывода печатных форм данные пересылаются с Prinergy обратно на Hiflex. Если в файле заказчика обнаружена ошибка и необходим повторный вывод, система добавит эту информацию в счёт. Hiflex в состоянии подготовить JDF-данные для предварительной настройки резального устройства Polar с помощью Heidelberg Compucut.
Отправить данные на этап подготовки макета можно посредством шаблона Acrobat Professional — программа скомпонует JDF-билет задания, при необходимости включив в него детали заказа вместе с информацией о клиенте. Приложения CS3, в т. ч. InDesign, для создания билетов заданий открывают Acrobat. Обычно дизайнеры либо не знают параметров печати, либо ими не интересуются. JDF-шаблоны Acrobat, пересылаемые им через АСУП, помогут решить проблему. В подготовленном шаблоне содержат-
ся оптимальные настройки
печати, а для добавления элементов дизайна его загружают в Acrobat. Готовый JDF-файл возвращается в АСУП/допечатную систему для автоматической обработки.
Ответственность за техническую поддержку и разработку спецификаций JDF лежит на организации CIP4. К ней может присоединиться любая профильная компания, выплачивая варьирующиеся годовые взносы.
Об авторе: Абхай Шарма, председатель школы графических коммуникаций при университете Ryerson (Торонто), член комитета CIP4 по образованию и маркетингу.
Переслать данные в начало производственного цикла, на этап создания макета, можно с помощью шаблона Acrobat Professional. Программа создаст JDF-оболочку работы. Представленная Muller Martini на Drupa система Connex предназначена для создания именно таких JDF-файлов.
Поставщики продолжают внедрять принудительную интеграцию. Но JDF прекрасно работает и без неё, как показала прошлогодняя конференция IPA
Автор сходу задаётся вопросом: «Жив ли JDF?». Неудивительно, что член CIP4 по образованию и маркетингу отвечает на него утвердительно. А вот полиграфистам-практикам уже приелись разговоры о JDF, хотелось бы видеть реальные примеры. Желательно — выходящие за рамки приводимого азбучного (JDF для спуска полос). Автоматизация производства уровня предприятия требует внедрения АСУП (она же MIS), а об успешном опыте в РФ ничего не слышно. Более того, есть примеры провальных инсталляций различных АСУП. Будем надеяться, что исполняемые ныне проекты завершатся успехом. Остаётся критикуемая автором кусочная интеграция пар продуктов. Вот таких примеров много, и они уже приносят практическую пользу. Широко распространена передача красочных профилей из препресс в пульт печатной машины или генерация JDF спусков полос. Более сложных и продвинутых примеров немного.
Из практики «Нисса Центрум» упомяну интеграцию в «Первом полиграфическом комбинате» спускового пакета (Kodak PREPS), АСУ ТП (Kodak Prinergy) и системы управления рулонными печатными машинами (manroland PECOM). В законченной системе на основании разбора имён файлов автоматически создаются спуски полос, выводятся пластины и с них печатаются, фальцуются готовые «кирпичи» изданий типа «Товары и цены». К сожалению, именно «кусковая» интеграция и является сегодняшней практикой использования JDF. Это хорошо видно из приводимой автором матрицы решений на www.cip4.org/matrix. Всего 35 пар продуктов, соединённых по JDF, находятся в реальной эксплуатации. Это в целом. Если взять наиболее требовательную в автоматизации часть — финишное оборудование, то у нас всего 3 (!) работающих в производстве пары.
Если темп сохранится, на вопрос «жив ли JDF?» придётся отвечать уклончиво. Чтобы этого не случилось, членам CIP4 следует перейти от заклинаний к полномасштабной практике интеграции. Пока в реальности — в основном «кусковой». Когда рабочих пар наберётся много, тогда из работоспособных блоков можно будет собирать работоспособную систему уровня предприятия. Создание Interoperability Conformance Specifications (ICS), спецификаций интеграции пар, даже не упомянутое автором, — важнейшая на сегодня задача CIP4. И процесс находится на ранней стадии. Первые спецификации АСУ ТП «Газетная печатная машина» (Newspaper: MIS to WebPress ICS) и АСУ ТП «Рулонная коммерческая печатная машина» (Commercial Web: MIS to WebPress ICS) опубликованы лишь в январе 2008 г. Нетрудно догадаться о степени их внедрения.
CIP4 можно поздравить с выходом 10 ноября новой 1.4 спецификации JDF в виде более чем 1000-страничного документа. Это, конечно, здорово, так как предыдущая 1.3 обросла за три года значительными исправлениями и добавлениями. Но это значит, что ныне нет ни одного продукта, сертифицированного на соответствие новейшей JDF-спецификации. Всё ещё впереди. — Михаил Кувшинов, директор по стратегии и маркетингу «НИССА Центрум»
