Что бы ни говорили дипломаты и поэты, главное достоинство языка - в ясности. Ф. Стендаль

Если вы следите за новостями и публикациями в отраслевых СМИ, то в последнее время уже неоднократно встречали аббревиатуру «JDF» и знаете об этом фактически все, что необходимо полиграфисту. А именно:

• drupa 2004 прошла под знаком JDF;
  
  
• JDF предлагает «беспрецедентные возможности» для «автоматизации полиграфического предприятия»;
  
  
• по прогнозам экспертов, в следующие пять лет (то есть к 2009 г.) вся полиграфическая отрасль перейдет на JDF-формат, поэтому:
  
  • нужно срочно приобрести (и, может быть, даже попробовать установить) некую могучую «автоматизированную систему управления предприятием»,
    
  • отныне покупать только оборудование, «поддерживающее JDF».
    
    
• В конце материалов о JDF в иностранных источниках обычно приводятся избранные success stories, например: небольшая английская типография за последние пару лет вложила скромную сумму в три миллиона фунтов стерлингов в модернизацию оборудования, что позволяет ей уже сейчас опережать менее расторопных конкурентов по срокам выпуска продукции (далее следует список модернизированного оборудования, в котором почему-то отсутствуют «Феррари» и «Мерседесы»).

Григорий САПУНКОВ, технический эксперт, «Курсив»

Казалось бы, приняв к сведению описанное выше, тему JDF можно закрыть и, не предпринимая каких-либо практических шагов, вернуться к повседневным делам. И терпеливо ждать 2009 г., когда можно будет с облегчением узнать, что прогноз скорого перехода на JDF-формат во всем мире сбылся (или не сбылся), или ждать drupa 2008, чтобы узнать новую аббревиатуру, которая станет следующим большим прорывом в полиграфии (после PDF и JDF). Однако, прежде чем читатель поступит таким образом, попробуем подытожить, что нам известно о формате JDF на сегодняшний день, отделим зерна разумного от маркетинговой шелухи и объясним причины нашего скептицизма (вернее, умеренного восторга) по поводу перспектив скорого наступления светлого JDF-будущего.

PPF: предшественник JDF

JDF - прямой наследник другой трехбуквенной аббревиатуры - PPF. Спецификация формата PPF (Print Production Format) была разработана консорциумом CIP3 (International Cooperation for Integration of Prepress, Press and Postpress), объединявшим три десятка крупнейших производителей полиграфического оборудования, роль секретаря выполняла организация под названием Fraunhofer Institute for Computer Graphics. Первоначальная инициатива создания такого консорциума и предложение по совместной разработке формата PPF исходила от компании Heidelberg, которая в 1995 г. переходила от состояния производителя только печатного оборудования к состоянию производителя полиграфического оборудования в целом (включая допечатное и послепечатное).

Мотивы создания формата PPF были просты и понятны: современное печатное и послепечатное оборудование имеет возможность электронной настройки при помощи компьютеризированных пультов и консолей. Однако использование автоматической настройки затруднено тем, что собственно полиграфическое задание существует в электронном виде только на допечатном этапе (рис. 1): исходные файлы с текстами и графикой компонуются в программе верстки в PostScript- (или PDF-) документы, собираются на печатном листе в программах спуска полос и отправляются на выводное устройство. С этого момента полиграфическое задание «живет» уже в материальной форме: пленки, пластины, отпечатанные листы и, наконец, готовая продукция. Впрочем, было одно исключение в этом процессе, когда печатные формы при помощи специального сканера превращались обратно в таблицу электронных данных и передавались в пульт печатной машины для предварительной настройки красочного аппарата.

Рис. 1. Схема выполнения полиграфического задания. Этапы, на которых задание существует в
электронном виде при традиционной организации производства, выделены цветом

Задача PPF-формата была - облегчить настройку печатного и послепечатного оборудования (в случаях, когда таковое оснащено компьютеризированными управляющими устройствами). С этой целью предполагалось сопровождать материалы задания (формы и отпечатанные листы) на этапах печати и послепечатной обработки неким PPF-файлом, в котором были бы прописаны параметры, необходимые для настройки печатной машины, резака, фальцовки или ВШРА (рис. 2). Такой файл должен был заменить бумажную спецификацию задания, передающуюся между цехами типографии в процессе производства.

Центральную роль в генерации PPF-файлов должны были выполнять программы спуска полос - как имеющие наибольшее представление о типах применяющихся печатных и послепечатных процессов. Морально устаревшие участки цепи (типа сканеров форм) предполагалось исключить и заменить более современным компьютеризированным оборудованием, способным работать с PPF-форматом. Поскольку PPF-файлы должны были возникать в конце допечатного этапа из исходных PostScript- (или PDF-) файлов, для описания конструкций PPF-формата был выбран тот же язык PostScript (с отдельными заимствованиями из PDF), а данные описывались как словари и DSC-комментарии. В отличие от обычных PostScript-файлов здесь уже не требовалось детального описания графического содержания задания (шрифтов, векторных и растровых элементов). Многомегабайтная графика оригинального PostScript- (или PDF-) файла требуется только для вывода форм, последующие этапы могут вполне обойтись небольшим изображением на экране монитора (для правильной идентификации задания) или растровым изображением с минимальным разрешением, необходимым для корректного расчета расхода краски при настройке печатной машины.

Таким образом, по спецификации консорциума CIP3 файл описания задания в формате PPF, необходимый на стадии печати и послепечатной обработки, должен содержать два необходимых типа элементов: растровое изображение листа с невысоким разрешением (для листовых машин обычно используется разрешение 50,8 dpi, для рулонных - 12,5 dpi) и поля с данными, описывающими размер и ориентацию печатного листа, параметры резки, фальцовки, брошюровки. Данные в PPF-файле должны быть указаны в аппаратно-независимой форме, чтобы не вызывать проблем при использовании устройств разных производителей. По этой причине формат PPF описывает технологические параметры производства задания, а не специфические настройки конкретных моделей полиграфической техники: получив PPF-файл, печатная или фальцевальная машина должна настроить себя сама.

Впервые спецификация CIP3 PPF была представлена на drupa 1995, первая рабочая система показана в августе 1995 г. Последняя версия спецификации PPF (3.0 модификация 1.0a) появилась в ноябре 2000 г. Вероятно, скоро мы увидим еще одну модификацию формата PPF как часть стандарта JDF 1.3.

Рис. 2. Схема выполнения полиграфического задания с использованием формата PPF. PPF–файлы, создающиеся на
допечатном этапе, используются для настройки печатного и послепечатного оборудования

PPF-формат был хорошим начинанием, увы, не получившим распространения в масштабах, задуманных его авторами. На наш взгляд, на то был ряд причин:

• PPF описывает только печатную и послепечатную стадию производства задания, совершенно не касаясь допечатного цикла. По этой причине генерация PPF-файла стала дополнительным «лишним» шагом допечатной подготовки. А для каждого лишнего шага в любом производстве должна быть оправданная необходимость. Авторы допечатного программного обеспечения отнеслись без должного энтузиазма к тому, что теперь им нужно обеспечивать информацию для всего послепечатного цикла и, например, указывать положение, размер и тип скрепки для ВШРА, учитывая, что устройств, воспринимающих такую информацию пока нет (а разработчики ВШРА, вероятно, ждали, когда появятся программы, создающие PPF-файлы с параметрами послепечатной подготовки, прежде чем добавлять соответствующую возможность настройки устройств). То, что в теории казалось замечательной идеей, на практике - когда потребовались вложения в разработку - стало вызывать определенные сомнения в необходимости.
  
  
• Спецификация PPF описывала только формат или структуру файла. О том, каким образом PPF-файл будет передаваться из допечатного отдела в печатный цех и на участок послепечатной обработки, авторы формата умалчивали. Учитывая, что размер файла не позволяет записывать его на дискету, да и использование внешних носителей в наше время кажется атавизмом, возникает необходимость объединить все участки производства в одну компьютерную сеть и организовать процесс передачи PPF-файлов между звеньями производственной цепи. Развитые системы контроля прохождения задания на тот момент существовали исключительно на допечатной стадии обработки и контролировали этапы получения файлов от заказчика, их проверки, спуска полос, печати пробных оттисков и вывода форм. Подключение к prepress workflow еще и печатного и послепечатного оборудования только с целью передачи PPF-файлов вряд ли было целесообразным. Соответственно, возникла необходимость создать систему контроля всего производственного процесса с возможностью интеграции в нее печатных и послепечатных устройств разных производителей. Спецификация PPF не давала ответ на вопрос, как это можно сделать. В итоге поддержка этого формата на практике вызвала дополнительные вопросы.
  
  
• Аппаратная независимость PPF была одной из целей, которую преследовали ее авторы. Но в результате это достоинство свелось к необходимости дополнительных шагов по обработке PPF-формата на каждом этапе производства. Так, например, PPF-файл содержит только растровое изображение, по которому дополнительный компьютер может рассчитать значения настройки красочных зон для конкретной печатной машины и передать их на пульт машины.
  
  В каком формате передаются эти значения - спецификация умалчивает, хотя способ настройки всех печатных машин примерно одинаков. Как результат, каждому производителю печатных машин пришлось изобретать свой собственный дополнительный формат файлов для передачи его на пульт печатной машины и устанавливать рядом с машиной еще один компьютер, роль которого сводилась исключительно к преобразованию PPF-файла в формат данных пульта. Как видим, стремление к аппаратной независимости породило хаос, которого можно было бы избежать, если бы спецификация была бы чуть более детальной.

На drupa 2000 были представлены первые системы, работающие с форматом PPF. Сравнительно полные решения с использованием печатного и послепечатного оборудования были представлены только на стендах Heidelberg и KBA, большинство остальных участников показали системы только для настройки красочного аппарата печатных машин. На этой же выставке был анонсирован формат JDF, призванный решить вышеописанные трудности.

PJTF: предшественник JDF

В то время как консорциум CIP3 активно работал над спецификацией PPF, компания Adobe стремилась продвинуть формат PDF и сделать его не только средством распространения электронных документов, но и форматом для профессионального полиграфического использования, заменой PostScript. На пути Adobe стояла одна существенная преграда, которая по совместительству была основным достоинством формата PDF - его аппаратная независимость. По первоначальной концепции авторов, PDF не содержит данных, задающих установки выводного устройства (ФНА, CtP или принтера). Благодаря этому PDF-файл можно посмотреть на экране или отправить на любое устройство без опасений, что при печати возникнет сбой из-за того, что при генерации файла использовались параметры другого устройства. По этой же причине настройки, которые можно задать при генерации PostScript-задания, например, установка разрешения или выбор лотка, из которого принтер должен брать бумагу определенного типа, в PDF-файле отсутствуют. Как результат, непосредственное использование PDF-файлов для цифровой печати или внутри prepress workflow было проблематичным.

Рис. 3. Классическая схема организации допечатного процесса с
использованием prepress workflow и «билетов задания»

Чтобы решить эту проблему, Adobe разработал дополнительную спецификацию - PJTF (Portable Job Ticket Format), которая должна была описывать аппартно-зависимые параметры печати PDF-файлов. Кроме параметров печати и установок печатного устройства, PJTF мог содержать параметры допечатной подготовки: префлайт, спуск полос, треппинг - и послепечатной обработки: обрезки и фальцовки, возможной на некоторых цифровых печатных устройствах. «Билет задания» (job ticket) в формате PJTF (который использует те же типы данных, что PDF-формат) может быть либо внедрен в тело PDF-файла, либо существовать независимо от него. Во втором случае в файле формата PJTF должен быть указан сетевой адрес к одному или нескольким PDF-файлам, составляющих графическое содержание задания.

PJTF фактически выполнял ту же роль, что и PPF, но если последний описывал параметры, необходимые для печати и послепечатной обработки, то PJTF был, в первую очередь, предназначен для допечатного цикла и цифровой печати. Кроме данных, описывающих параметры допечатной подготовки, PJTF также содержал дополнительные конструкции, при помощи которых звенья prepress workflow могли передавать данные о результатах своей работы следующему звену обработки (рис. 3).

Формат PJTF не получил большого распространения по двум основным причинам:

• К моменту его появления фактически все производители допечатных систем workflow использовали «билеты» для сопровождения печатных заданий PDF в своих собственных закрытых форматах. Причем, по заявлениям разработчиков, их собственные форматы содержали существенно больше нужной информации о печатном задании, чем позволял формат PJTF.
  
  
• Поскольку системам workflow разных производителей редко приходится обмениваться данными между собой (на предприятии обычно установлена только одна система), то и насущной необходимости в использовании общего открытого формата типа PJTF не возникало.

JDF: наследник PPF и PJTF

В то время как на drupa 2000 демонстрировались первые системы, использующие формат PPF для настройки печатного и послепечатного оборудования, четыре компании, члены консорциума CIP3: Adobe, Agfa, Heidelberg и MAN Roland (иногда эти компании упоминаются как «банда четырех») - представили публике проект новой более универсальной спецификации под названием JDF (Job Definition Format). Летом того же года дальнейшая разработка формата была передана консорциуму CIP3, который по этому поводу был переформирован в открытую общественную организацию и переименован в CIP4 с добавлением еще одной буквы P, означающей «Processes», к оригинальному названию (теперь полное название следует читать так: International Cooperation for In-tegration of Processes in Prepress, Press and Postpress). В CIP4 входят не только крупные производители, но и «простые смертные» (разработчики, консультанты, представители типографий, издательства), желающие внести свою лепту в разработку формата JDF. На сегодняшний день в CIP4 более 270 членов (вообще говоря, удивительно, что такое число участников может не только работать над чем-то совместно, но и добиваться результата).

Рис. 4. Рекомендуемая схема организации производства с использованием формата JDF.
Управляющая MIS-система обеспечивает контроль всех шагов выполнения задания

Что же такое формат JDF и в чем его универсальность? JDF не является абсолютно новой разработкой «с нуля» - использует в качестве основы имеющиеся достижения PPF и PJTF: из формата PPF позаимствованы технологические параметры описания печатного и послепечатного процессов, из формата PJTF - параметры и структура шагов допечатной подготовки. Как результат, JDF может использоваться для описания параметров всех этапов производства задания: допечатного, печатного и послепечатного. Кроме того, подобно PJTF, различные участники процесса выполнения задания могут изменять параметры задания и добавлять в него новую информацию, а ресурсы (например, графическое содержание полос работы) не встроены в тело файла-задания, а задаются как ссылки на внешние объекты. На этом сходство между ранними форматами и JDF заканчивается и появляются концептуальные отличия:

• Формат JDF ставит целью интегрировать не только допечатные, печатные и послепечатные процессы в единый механизм, но и подключить к производству «бухгалтерские» системы управления предприятием (В этой статье мы не будем использовать русскоязычных аббревиатур типа СУБД или АСУП, принятых среди специалистов по базам данных и прочей бухгалтерии, поскольку наш рассказ рассчитан на «более широкий круг читателей», работающих в полиграфической сфере). Эти системы, осуществляющие такие важные функции, как формирование заказа, выписка счетов, управление складом, до текущего момента были, как это ни парадоксально, единственным «белым пятном» на карте автоматизации полиграфического производства. Если то, как наладить связь между РИПом и печатной машиной, было в общих чертах понятно, то как сообщать данные о ходе выполнения заказа менеджеру, ведущему работу с клиентом, не знал никто. Роль информационных систем на полиграфическом предприятии была очень мала: она начиналась с приема заказа и заканчивалась через пять минут выпиской счета и резервированием на складе нужного количества бумаги и краски. Как результат, многие даже крупные компании не видели смысла в приобретении «развесистых» информационных систем управления предприятием за много тысяч долларов и предпочитали обходиться подручными средствами: электронными таблицами MS Excel или простенькими базами данных MS Access.
  
  JDF призван в корне изменить сложившуюся ситуацию. Теперь информационным системам отводится ключевая роль: они должны не только организовывать прием заказа и резервировать складские ресурсы, но и управлять всем процессом выполнения задания, отправляя его последовательно разным звеньям производственной цепи (рис. 4). Кроме того, наконец-то дан ответ на вопрос, кто должен создавать Job Ticket и исходное описание заказа: менеджер, принимающий заказ, или сам пользователь, отправляющий исходные файлы в типографию. Далее, по мере перемещения заказа по звеньям производственной цепи, его описание будет «обрастать» технологическими подробностями: параметрами спуска полос, данными об обрезном формате, спецификацией фальцовки и т. д.
  
  
• Для того, чтобы звенья производственной цепи могли общаться между собой на общем языке, в спецификацию JDF включен еще один формат (помимо собственно JDF) - JMF (Job Messaging Format). При помощи JMF отдельные звенья получают указания от информационной системы MIS (Mana-gement Information System) выполнять то или иное задание, а система (и сотрудник, отслеживающий состояние заказа имеют возможность получить информацию о ходе выполнения работы. Причем, не просто в виде сухого и короткого сообщения, например, «работа находится в печатном цехе», а полный подробный отчет: «Идет печать оборота третьего листа, отпечатано 2500 листов из 10000, скорость печати 5000 отп/ч».
  
  JMF позволяет избавиться от устаревшей схемы управления оборудованием, сложившейся во время развития PPF, по которой в печатном цеху или на участке послепечатной обработки должны находиться дополнительные управляющие компьютеры, роль которых - преобразовывать информацию PPF-задания в понятный оборудованию формат или командный язык. Теперь, если оборудование поддерживает формат сообщений JMF, оно может получать (или посылать) запросы напрямую из информационной системы, управляющей производством.
  
  
• Другая причина, по которой станет возможно избавиться от лишних управляющих компьютеров, - спецификация JDF существенно более детализированная, чем PPF. При сохранении общей аппаратной независимости JDF содержит намного больше структур данных, описывающих не только технологические параметры задания, но и общие возможности использующегося оборудования. Так, например, если для настройки печатной машины при помощи файла PPF производителю машины требовалось разрабатывать специальный компьютер, который на основе растрового изображения файла рассчитал бы значения зон для конкретной печатной машины и передал бы их на пульт во внутреннем формате машины, то при использовании формата JDF эта процедура упрощается, поскольку JDF позволяет описывать как основные параметры печатной машины, необходимые для расчета, так и уже рассчитанные индивидуальные значения красочных зон. Теперь пульту печатной машины требуется всего лишь получить JDF-файл с готовыми значениями зонной регулировки. А компьютерные системы расчета от разных производителей можно заменить одной универсальной программой, которая будет получать параметры расчета для данной печатной машины из входящего JDF-задания и отправлять рассчитанные значения пультам также в виде JDF-задания.

Как устроен формат JDF?

Полное и подробное описание формата JDF можно найти на веб-сайте консорциума CIP4 (http://www.cip4.org/). Версия спецификации JDF 1.2, вышедшая в мае 2004 г., в отличие от более ранних вариантов 1.1 и 1.1а, является уже «полнофункциональной», то есть ее можно использовать для создания не прототипов, а вполне работоспособных систем. Мы не будем вдаваться в тонкости этой спецификации, насчитывающей более 800 страниц, и использующейся в ней терминологии. Остановимся на ряде ключевых моментов:

Подобно другим современным форматам и языкам описания данных, JDF основан на языке XML. Причин для этого несколько:

• во-первых, при создании JDF-систем достаточно много работы ложится на плечи разработчиков информационных систем, для которых XML является более простым и доступным языком, чем PostScript или PDF;
  
  
• во-вторых, XML - гибкое и удобное средство, позволяющее описывать любые структуры данных;
  
  
• в-третьих, поддержка XML встроена в большинство современных средств, так что разработчикам не потребуется дополнительных усилий по работе с этим языком;
  
  
• в-четвертых, XML обладает таким элементом, как «XML-схема», позволяющим проверять корректность задания перед его выполнением. Учитывая, что JDF-системы должны отправлять и получать данные звеньям производственной цепи, созданных самыми разными производителями, возможность такой проверки весьма весомый аргумент в пользу XML.

Подобно PJTF и другим форматам Job Ticket, ресурсы JDF-задания, например, графическое содержание полос в форматах PostScript или PDF, задаются как ссылки (URL) на внешние ресурсы, находящиеся в локальной сети или интернет-серверах. Частично это вызвано тем, что язык XML не позволяет включать такие объекты в тело файла, но, как положительный момент, такая организация ресурсов позволяет сохранять размер JDF-задания минимальным, что облегчает процесс его передачи по компьютерной сети. Кроме того, появляется возможность размещения ресурсов на удаленных серверах и передачи их по сети только при необходимости.

Структура JDF-задания достаточно проста: файл состоит из иерархии узлов (nodes), где каждый узел описывает либо составную часть задания (например, обложка или внутренний блок страниц), либо процесс, необходимый для выполнения этой части (например, спуск полос, вывод форм или фальцовка). На рис. 5 приведен пример структуры JDF-задания. На верхнем уровне иерархии расположен узел, соответствующий всей работе (например, брошюра из 36 страниц с обложкой), под этим узлом расположены три других:

Рис. 5. Пример структуры JDF-задания

• первый описывает внутренние страницы задания и содержит другие узлы, определяющие процесс их допечатной подготовки, печать и послепечатные действия;
  
  
• второй соответствует обложке и процессам, необходимым для ее производства;
  
  
• третий узел - это процесс общей сборки готовой брошюры из внутренних страниц и обложки.

В каждом узле могут присутствовать два типа данных: описания параметров процесса или работы и описание входных и выходных ресурсов. Выходные ресурсы одного из процессов обычно являются входными для других, последующих. Система, управляющая выполнением JDF-задания, отправляет его на выполнение звеньям системы, способным осуществить тот или иной процесс, по мере готовности ресурсов для этого процесса. Так, например, готовые для вывода спуски полос являются выходным ресурсом для процесса спуска полос и входным для процесса изготовления форм. Пока система спуска полос не отправит сообщения о готовности PostScript- или PDF-файлов, работа не будет направлена на CtP. Рис. 6 показывает порядок выполнения JDF-задания со структурой на рис. 5.

Рис. 6. Порядок выполнения JDF-задания со структурой на рис. 5

Кроме того, участники процесса обработки JDF могут добавлять в задание статистическую информацию о времени, потребовавшемся на выполнение задания, и возникших при этом проблемах.

Формат JMF-сообщений является составной частью спецификации JDF. Его задача - посылать команды на выполнение JDF-задания из управляющей системы звеньям, осуществляющим тот или иной процесс, и получать от них сообщения о выполнении и текущем состоянии. Существует два способа это сделать: либо при помощи «горячих папок», либо при помощи протокола HTTP. При первом способе может возникнуть ряд проблем: необходимо, чтобы и управляющая система, и устройство, выполняющее процесс, имели доступ к входным и выходным папкам (а это определенная угроза компьютерной безопасности), нужно периодически сканировать папки и отслеживать появление новых сообщений, необходимо, чтобы не возникало ситуаций с конфликтом имен файлов и т. д. С другой стороны, это более «реалистичный» подход, не требующий от разработчиков необходимости включать в свои продукты функциональности клиентов и серверов HTTP-протокола и, тем самым, ускорить выход первых версий JDF-продуктов.

Варианты построения JDF-систем

Спецификация JDF не содержит детальных инструкций о том, какой именно должна быть конфигурация системы, работающей с JDF-форматом. Подобные рекомендации лишили бы идею JDF ее гибкости и сузили бы круг возможного применения формата. Напротив, в качестве основной рекомендации по применению JDF можно услышать, что для начала надо произвести анализ методов работы своей типографии и, если нужно, на отдельных участках перейти к использованию формата JDF.

В идеале, процессом обработки JDF-задания должна управлять всеобъемлющая система управления полиграфическим производством, контролирующая все этапы работы с заказом: от приема, выписки счета и резервирования материалов, через все этапы допечатной, печатной и послепечатной обработки до получения заказчиком тиража. Очевидно, что для создания такой системы необходима интеграция в нее всех функций обычной системы prepress workflow (префлайт, спуск полос), что потребует от ее создателей не только знания бухгалтерского учета, но и четкого представления о, например, элементах допечатного цикла (префлайте или треппинге). К тому же, системы prepress workflow уже достаточно развиты и отлажены, так что большинство существующих на рынке систем управления полиграфическим предприятием не пытаются их заменить, а лишь интегрируют в свой состав методом обмена с ними JMF-сообщениями о текущем состоянии заказа.

Рис. 7. На drupa 2004 монитор на стенде Muller Martini отображал
при помощи JMF-сообщений информацию о загруженности оборудования

Если на предприятии нет системы управления производством, поддерживающей JDF, можно ограничиться использованием этого формата только в системах prepress workflow или печатном и послепечатном циклах, то есть заменить им другие закрытые форматы Job Tickets и формат PPF. Благодаря использованию JMF-сообщений системы и устройства различных производителей смогут общаться друг с другом на понятном языке.

Рис. 8. JDF-производство в павильоне PrintCity: система приема заказов Optimus 2020

При полном отсутствии систем управления производством и систем prepress workflow, способных контролировать отдельные этапы при помощи JMF-сообщений, использование JDF можно свести просто к обмену электронной спецификацией задания между устройствами и программами, поддерживающими JDF через серию «горячих папок», даже без использования механизма JMF-сообщений.

JDF: текущее состояние

На текущий момент выставка drupa 2004 была крупнейшей демонстрацией JDF-технологий. Подводя итоги выставки, можно сказать, что принятие формата JDF различными производителями программного обеспечения и допечатного/печатного/послепечатного оборудования превосходит ожидания или результаты принятия формата PPF четырьмя годами раньше. JDF был, пожалуй, крупнейшим событием на drupa, и если сравнение эффекта, который формат JDF будет иметь для полиграфической отрасли, с эффектом появления языка PostScript кажется чрезмерным, то, что это самое значительное событие в полиграфии с момента появления PostScript, споров не вызывает.

Все крупные игроки в полиграфической отрасли представили на drupa 2004 оборудование или системы, поддерживающие формат JDF, на многих стендах можно было увидеть живую презентацию: экраны компьютеров в реальном времени показывали процесс производства заданий, происходящих в одном или нескольких стендах и павильонах. Так, например, на стенде Muller Martini можно было наблюдать процесс выполнения работы на послепечатном оборудовании этой компании, находящимся в нескольких разных павильонах (рис. 7), обмен данных о состоянии оборудования производился посредством JMF-сообщений. Другой интересной экспозицией был стенд Heidelberg, где посетители могли наблюдать, как допечатные, печатные и послепечатные устройства этой компании по очереди принимали участие в выполнении одного задания под управлением информационной системы. Еще более любопытным был JDF-стенд в павильоне PrintCity. Здесь похожий совместный процесс выполнения одного задания можно было наблюдать на устройствах и системах разных производителей группы Print City. Посетитель выбирал задание, указывал свое имя клиента в системе приема заказов Optimus 2020 (рис. 8) и далее мог наблюдать, как JDF-задание поступает в систему отслеживания заказа ppi, систему допечатной подготовки :Delano Publish, выводится цветопроба на струйном принтере под управлением РИП Harlequin, затем создаются спуски и формы при помощи системы :ApogeeX (рис. 9), заказ печатается на машине MAN Roland под управлением системы PECOM (рис. 10) и проходит послепечатную фазу на системах от MBO, Wohlenberg и Muller Martini. В итоге посетитель получал экземпляр готовой продукции со своим именем на обложке. Наблюдая этот процесс, возникало чувство восхищения, что все эти системы разных производителей, выполняющие самые разные операции общаются на общем языке JDF.

Рис. 9. JDF-производство в павильоне PrintCity: система prepress workflow Agfa :ApogeeX

Наибольшего прогресса по освоению JDF на drupa 2004, как нам кажется, достигли производители информационных систем и допечатного оборудования. В этой области можно было наблюдать не только старые системы, модернизированные для использования формата JDF, но и ряд совершенно новых продуктов, специально разработанных с функциями поддержки JDF. Что касается печатного и послепечатного оборудования, то здесь изменений несколько меньше: то, что мы видели, скорее, напоминает не модульную реализацию по JDF-схеме, а дальнейшее развитие схемы поддержки формата PPF с едиными управляющими компьютерами, рассылающими команды подключенным к ним устройствам на своем внутреннем языке. С другой стороны, то, что эти управляющие центры (типичный пример: i2i System от Horizon (рис. 11) могут общаться с информационными системами через JMF-сообщения, уже достаточно серьезный шаг вперед. Хочется надеяться, что скоро мы увидим разработки, в которых поддержка JDF реализована непосредственно в устройствах, осуществляющих настройку печатного и послепечатного оборудования, а не в дополнительных управляющих системах, созданных только с целью поддержки JDF.

Приятной новостью было то, что компания Adobe собирается интегрировать базовые функции создания JDF-заданий в свои программы InDesign и Acrobat. Пакет Acrobat 7, вышедший в январе 2005 г., выполняет это обещание и содержит возможности создания пользовательского описания JDF-продукта. Другой хорошей новостью 2004 г. было то, что даже компания Quark (известная не очень адекватной реакцией на события внешнего мира) вступила в консорциум CIP4 и, более того, стала участником «группировки» производителей NGP (см. ниже).

В качестве источника информации о состоянии JDF-продуктов можно рекомендовать периодическую публикацию консорциума CIP4 - The JDF Marketplace, однако мы бы посоветовали относиться к ней осторожно, поскольку в ней содержится не вся информация, а лишь та, которую не поленились предоставить участники CIP4. Кроме того, в этом документе есть ряд неточностей. Например, в февральской версии документа этого года можно заметить, что компания Dainippon Screen почему-то рекламирует свои продукты с ссылкой на веб-сайт другой японской компании Ryobi. Некоторые из продуктов, упомянутые в этой публикации поддерживают только формат PPF или могут быть использованы лишь для работы с PDF-форматом. Так или иначе мы бы посоветовали воспринимать этот источник как «один из многих» маркетинговых материалов, а не единственный заслуживающий доверия...

Война JDF-группировок?

Хотим напомнить то, что происходило перед выставкой: если перед drupa 2000 мы стали свидетелями объединения некоторых крупных производителей в группу под названием PrintCity, ставящей своей целью совместную демонстрацию оборудования и его интеграцию на крупных выставках, то перед drupa 2004 была создана другая ассоциация, известная как NGP (Networked Graphic Production), основным идеологом которой была компания Creo. Члены NGP (все из них - участники консорциума CIP4) ставили своей задачей убедиться и договориться, что оборудование и системы, которые они производят, способны общаться друг с другом посредством JDF-формата.

Рис. 10. JDF-производство в павильоне PrintCity: система управления печатным оборудованием MAN Roland PECOM

Цель создания NGP примерно такая же, как и у PrintCity: сделать возможной демонстрацию готовых систем на выставках (в частности, на drupa 2004). Причина создания NGP довольно простая: производители того или иного вида оборудования не могли понять, какую часть 564-страничной спецификации JDF 1.1a они должны поддерживать, чтобы добиться совместимости с продуктами других производителей. Это не значит, что продукты участников NGP менее совместимы с форматом JDF, чем продукты других членов CIP4, наоборот, целью NGP было убедиться, что они поддерживают ее нужным, понятным другим образом. Возникновение группировок PrintCity и NGP вовсе не означает, что после JDF-революции началась «гражданская JDF-война». Согласно комментарию консорциума CIP4, рекомендации NGP по использованию формата JDF и сам формат JDF можно сравнить с установками, использующимися при дистилляции PostScript-файла в формат PDF, и самим форматом PDF. Объединение NGP - всего лишь попытка создать некоторое подмножество JDF, понятное оборудованию и системам других членов этой группы.

Консорциум CIP4 пытается решить проблему, поставленную NGP в версии спецификации JDF 1.2, расширив описание формата и типов JMF-сообщений, при помощи которых системы и устройства обмениваются информацией о своих возможностях. Кроме того, CIP4 работает над рядом дополнительных документов, известных как ICS (Interoperability Conformance Specification). Эти спецификации будут содержать список JDF-параметров, обязательных для поддержки оборудованием различного типа: допечатного, печатного, послепечатного. Теперь производителю фальцевального оборудования подробно объясняется, обработку каких ресурсов и полей данных JDF-файла он должен реализовать в своей системе. Прочие параметры, например, относящиеся к процессам префлайта, вывода форм или резки, производитель фальцовок может смело игнорировать. Первые документы ICS стали доступны публике в конце января 2005 г. Они описывают требования по интеграции систем управления MIS с допечатными системами, оба этих типа систем с листовыми печатными машинами и некоторыми системами ВШРА (в частности, с цифровыми печатными машинами с возможностями послепечатной обработки). На очереди выход других спецификаций, описывающих остальные полиграфические процессы. При полной поддержке соответствующих спецификаций ICS производителями оборудования дальнейший смысл в подмножествах JDF, созданных группами типа NGP или Print-City, постепенно пропадет.

Создание спецификаций ICS также является началом процесса сертификации программ и оборудования на «JDF-совместимость» (JDF Certified), в качестве тестирующей организации CIP4 избрал GATF (Graphic Arts Technical Foundation), объединяющую более 13 тысяч различных компаний по всему миру. Тестирование и сертификация на JDF-совместимость должны вот-вот начаться.

Наши рекомендации

В заключение попробуем сформулировать наши рекомендации по внедрению формата JDF в производственный процесс типографий. Повторим еще раз основные преимущества, которые может дать использование JDF, и попробуем понять, что может потребоваться для их реализации.

• Упрощение приема заказов. Если клиент предоставляет JDF-спецификацию заказа вместе с исходными PostScript- или PDF-файлами, а система приема заданий поддерживает формат JDF, то это упрощает процедуру ввода нового заказа в систему: информация о клиенте, составных частях работы, требуемом тираже, типе бумаги и т. д. автоматически вносится в базу данных. Такая возможность делает проще обсуждение заказа с клиентом и уменьшает вероятность ошибок и недопонимания. Заказчик для создания JDF может пользоваться «стандартными» средствами, например, программой Adobe Acrobat 7.0. Типографии потребуется приобрести систему управления производством, поддерживающую JDF, или хотя бы модуль по работе с клиентами из ее состава. В простейшем случае в типографии может использоваться тот же Adobe Acrobat 7.0, а информация будет заноситься во внутреннюю базу данных или в «паспорт задания» менеджером вручную.
  
  Нужна такая возможность вашей типографии - решать вам. Если какая-то часть работ уже принимается (или будет приниматься) через интернет, об этом стоит задуматься.
  
  
• Автоматическая настройка допечатного, печатного и послепечатного оборудования. Если в типографии установлено современное оборудование с возможностью настройки при помощи файлов в форматах JDF или PPF, использование этих форматов позволяет ускорить выполнение задания. Для этого необходимо суметь создать файл задания (или получить его от клиента) и добавить в него параметры, необходимые для настройки соответствующего оборудования.
  
  Прежде чем делать инвестиции в устройства и программы, необходимо разобраться, какое из имеющегося в типографии оборудования поддерживает автоматическую настройку, какие программные средства способны создавать соответствующие JDF- и PPF-файлы и каким образом наиболее удобно наладить передачу файлов между программами и оборудованием. Возможно, не стоит вкладывать деньги сразу в «могучую» автоматизированную систему управления, а на первых этапах, пока идет модернизация оборудования для поддержки JDF, обойтись более доступными средствами, выполняющими отдельные операции: только создание файла для настройки печатной машины или послепечатной техники.
  
  
• Управление процессом выполнения задания и отслеживание текущей занятости оборудования. Пожалуй, это наиболее интересная возможность, предлагаемая форматом JDF. К сожалению, здесь уже невозможно будет обойтись без автоматизированной информационной системы. Перед ее приобретением надо всесторонне взвесить преимущества, которые она может дать, и понять, есть ли вообще необходимость в ее применении. Так, например, в небольшой типографии с одной-двумя печатными машинами, резаком, фальцовкой и ВШРА производственный процесс, скорее всего, и так хорошо налажен, и использование системы управления не потребуется. На крупном предприятии с несколькими рулонными и листовыми машинами, а также более богатым выбором послепечатного оборудования, использование системы, перераспределяющей нагрузку оборудования оптимальным образом, может иметь достаточно большой экономический эффект.
  
  Опять же на этапе модернизации оборудования можно ограничить использование JDF-формата только административными системами (прием заказа и резервирование расходных материалов) или использовать его только на допечатном этапе в системах prepress workflow. Затем, по мере появления совместимого печатного и послепечатного оборудования, интегрировать различные части системы в единый производственный процесс на основе JDF.

Рис. 11. Управляющий центр послепечатной обработки Horizon i2i System

Заключение

Нет сомнений, что формат JDF предлагает новые беспрецедентные возможности по объединению всего полиграфического оборудования в единый комплекс под управлением одной информационной системы. Создание и развитие этого формата, пожалуй, самый серьезный шаг, который полиграфическая отрасль предприняла за всю свою историю. Сравнение эффекта, который может дать использование формата JDF, с революцией, вызванной возникновением языка PostScript, не вполне корректно, поскольку последний революционизировал лишь допечатные процессы, оставляя печатный и послепечатный циклы без изменений на протяжении десятилетий. JDF же должен изменить лицо всей полиграфической отрасли и автоматизировать весь производственный процесс.

Конечно, прогнозы об общем переходе на JDF в ближайшие пять лет можно отнести, скорее, к области фантастики (подобно построению коммунизма к 1980 г. или высадке человека на Марс к 2000 г.), но не будем отрицать, что после очередного цикла замены оборудования в следующие 10–15 лет масса JDF-совместимого оборудования станет критической и не использовать этот формат на предприятии будет уже невозможно. С другой стороны, форсировать такой переход в типичной отечественной типографии сегодня вряд ли имеет смысл. Давайте посмотрим, что будет дальше, дождемся выхода оставшихся спецификаций ICS и новых версий формата JDF, посмотрим, как производители сумеют договориться и наладить беспроблемный диалог между своими устройствами, увидим новые демонстрации на Ipex 2006 и drupa 2008 и только после этого решим, будет ли у нас JDF-будущее и окажется ли оно таким светлым, как обещают.