Файлы
PDF могут быть сгенерированы различными способами.
Формат PDF может служить
идеальным интерфейсом между версткой и типографией
Одна из самых неприятных и опасных тенденций в человеческом обществе — «кампанейщина» любых видов. Этакое, знаете ли, ильфо-петровское: «Ударим автопробегом по бездорожью и разгильдяйству!». Или, если угодно, «ударим PDF’ом по %PostScript error’у и раздутым файлам» — суть та же. В ходе умело проводимой кампании индивидуумы теряют критическое мышление и превращаются в толпу. Осуществляются неоправданные инвестиции, а потери и отсутствие желаемых успехов всегда можно списать на «перегибы на местах». Именно поэтому, когда очередную новинку объявляют панацеей, ложка дегтя в виде небольшой порции здравого смысла представляется вполне уместной.
Прежде чем провозглашать безвременную кончину PostScript и здравицы в честь PDF, давайте попробуем разобраться:
Начнем с истории. Язык PostScript был создан в середине 80-х годов фирмой Adobe как универсальный язык управления абстрактным графическим устройством, реальным прототипом которого выступал лазерный принтер. Надо сказать, отнюдь не первый язык такого рода. С точки зрения математики, задача управления графическим выводом была решена полностью и окончательно уже в тот момент, когда матричный принтер Epson-FX (или ему подобный) научился ставить одну-единственную точку в точно указанной позиции.
К сожалению, с точки зрения здравого смысла способ «поточечного» вывода для практического применения был слишком медленным и малоэффективным, поскольку требовал передачи на принтер информации о цвете каждой точки — и черной, и белой (цветных принтеров тогда еще не было вовсе). Во-первых, эта информация явно избыточна (большая часть листа все равно остается белой), во-вторых, управляющий компьютер (тот, с которого производится печать) вынужден просчитать в памяти всю картинку с точностью до отдельного пиксела, прежде чем приступить к выводу. А если учесть, что типичными характеристиками рабочей станции в те времена было «4 Мбайт ОЗУ/40 Мбайт — жесткий диск», становится ясно, что для массового применения процедуры графического вывода были слишком долгими и ресурсоемкими.
По мере расширения собственного интеллекта принтеров, база языков управления смещалась от оперирующих с отдельными точками к векторно-ориентированным, базирующимся на системе команд перьевого графопостроителя. Принтер стал получать команды типа «провести линию из точки А в точку В» или «напечатать символ А в позиции X,Y». Формирование каждой точки и полного растрового образа страницы стало прерогативой принтера, для чего в его аппаратную часть, помимо собственно печатающего механизма, стал включаться довольно сложный специализированный компьютер.
Прекрасно справляясь с задачами печати из офисных приложений, языки управления принтерами «до-PostScript’овского» времени (типа успешно сохранившегося PCL) плохо подходили для работы в зарождавшихся настольных издательских системах. Компания Adobe нацелилась на решение трех существенных проблем:
Для их решения была создана первая версия языка управления Adobe PostScript. Он существенно отличается от предшествующих языков следующим:
1. Базой описания кривых как в символах шрифта, так и в графике стали кривые Безье или кубические сплайны. В отличие от широко распространенных до этого дуг окружностей и квадратичных парабол, кривые Безье обеспечивают более гладкую аппроксимацию контуров по меньшему количеству точек.
2. PostScript-принтер не разделяет память для хранения шрифтов и рабочую область для формирования картинки, увеличивая эффективность использования памяти и разрешая загрузку произвольного числа шрифтов с произвольным количеством символов в каждом.
3. PostScript является полноценным языком программирования, в отличие от предшествующих языков управления, представлявших собой линейные последовательности команд. Повторяющиеся фрагменты кода определяются как подпрограмма, которая вызывается сколько угодно раз. Если для разметки странички тетради «в линейку» обычный язык управления содержит сотню последовательных команд «провести линию», PostScript может содержать единственный цикл, эквивалентный инструкции «провести линию сто раз с таким-то шагом». Количество информации и эффективность исполнения повышаются если уж не в сто, то в десятки раз.
Приведенный перечень преимуществ и особенностей языка PostScript (возможно, неполный) объясняет его быстрый успех. Фирма Adobe сделала PostScript базой внутреннего кода программы Adobe Illustrator и создала на его основе формат данных EPS — encapsulated PostScript, ставший ведущим форматом межпрограммного и межплатформенного переноса векторной информации в издательских системах. В соответствии с логикой PostScript, EPS-файл представляет собой просто определение подпрограммы, которое можно поставить в PostScript-код для вывода «как есть», снабдив лишь командами позиционирования на странице и (возможно) масштабирования.
С появлением лазерных экспонирующих устройств высокого разрешения PostScript естественным образом стал основным языком для вывода информации через эти устройства. Последующие полтора десятилетия внесли мало изменений в принципиальную структуру языка. Хотя появились продвинутые версии Level 2 и 3 (без Level), изменения в наибольшей степени касались возможностей включения в PostScript информации управления выводными устройствами (многокрасочное цветоделение, вывод цветных изображений, включение ICC-профилей цветоделения и т. д.) и расширения поддерживаемых форматов графики, включенной в PostScript (сначала был разрешен TIFF, затем JPEG, цветные изображения в модели RGB и т. д.). В основе своей PostScript как язык описания графических объектов с обратной нотацией не претерпел никаких изменений.
Все прекрасно, скажет нетерпеливый читатель, но почему тогда речь зашла о замене столь удачной технологии на что-то другое? Очевидно, недостатки у языка PostScript были. И, как ни парадоксально, недостатки PostScript вплотную примыкают к его достоинствам.
Во-первых, PostScript является языком программирования, а не просто форматом данных. Если для обычного формата управления графикой результат выполнения каждой отдельной команды и может измениться, скажем, при изменении разрешения, то взаимное влияние команд полностью отсутствует. С программой PostScript дело обстоит иначе. Даже не очень опытный программист объяснит, что для любого языка программирования результат работы на разных платформах и разных компиляторах (или интерпретаторах) может и, как правило, будет различаться. Не очень сильно, но будет. Поэтому программу, предназначенную для исполнения на разных платформах, долго и тщательно тестируют и отлаживают на каждой из них. Но в случае языка PostScript программа — это сам файл, подлежащий выводу. Исполнение — это вывод файла. Никто не может позволить себе заниматься тестированием и отладкой, поэтому файл должен быть закодирован с максимальным использованием информации о том выводном устройстве, на котором будет осуществляться вывод. Попытка вывести на Linotronic PostScript-файл (читай: исполнить на Linotronic-RIP PostScript-программу), подготовленный для Harlequin, может с полным правом не увенчаться успехом или привести к выводу чего-то неправильного.
Итак, отмечаем первый «грех» — неуниверсальность. Для каждой платформы, т. е. для каждого RIP, PostScript должен делаться индивидуально, причем с учетом конкретных параметров вывода (линиатура, разрешение и т. д.). Это не было проблемой в момент создания языка — никто тогда и не предполагал, что файлы в формате PostScript будут возить на другой конец города (или пересылать по телефону), чтобы там вывести. Это стало проблемой теперь, когда пользователь вынужден перебрасывать заказ на вывод из одного репроцентра в другой, иногда в последний момент, когда файлы уже готовы к выводу.
Позвольте, скажет внимательный читатель, у меня в верстке стоят иллюстрации в формате EPS, которые, как было сказано выше, помещаются в PostScript «как есть». Как же с ними быть в плане переносимости? Ответ простой — «как есть». В принципе, внутрь EPS не помещается никакой особой информации о разрешении вывода, линиатуре и других специфических для данного устройства параметрах. Но если при пересчете векторной иллюстрации, записанной в EPS с разрешением 800 dpi «по умолчанию», на реальное разрешение вывода 2540 dpi растровый процессор (интерпретатор PostScript) «зациклится» или выдаст сообщение об ошибке — будьте спокойны и терпеливы. Это второй «грех» PostScript — нестабильность и негарантированность результата. Хотя в подавляющем большинстве случаев причина сбоев такого рода кроется в неправильных действиях верстальщика, это не решает проблемы. Де-факто, вы можете быть на 100 % уверены в успешном растрировании конкретного PostScript только при условии, что этот файл уже был когда-то успешно растрирован на такой же версии RIP с теми же параметрами. В остальных случаях мы можем говорить лишь о доле уверенности в успехе — возможно, очень высокой, но никогда не достигающей уровня гарантированного результата. Для дополнительного «сгущения красок» приведу простой пример — как делается PostScript, приводящий к «зависанию» RIP с довольно высокой вероятностью.
Проблемам, связанным с использованием шрифтов, можно посвятить отдельную статью. Дело в том, что в PostScript определены три возможности работы со шрифтами:
Шансы получить правильный вывод в условиях России1 есть только во втором случае. К сожалению, слабая диагностика не позволяет определить, что при генерации PostScript’a пропущен необходимый шрифт. Как следствие, подготовленный на основании одних и тех же исходных данных файл будет успешно выведен на одном RIP, на другом «съедет» верстка, на третьем вместо текста вылезут «зюквы». И лишь четвертый, вместо того чтобы заниматься ерундой, выдаст вам любезное сообщение «font Helvetica_Сyrillic not found). Итак, записываем на счет PostScript очередной «грех» — плохую диагностику подстановки шрифтов.
Хотя в последнее время все реже и реже, но до сих пор встречается ситуация, когда какой-либо специфический шрифт прекрасно выводится на экране и на принтере с низким разрешением, а при попытке вывести фотоформу с высоким разрешением RIP выдает сообщение об ошибке. Особенно неприятно, когда ошибка возникает при работе со шрифтом, казалось бы, много раз проверенным — при попытке установить его в повернутое на «произвольный угол» окно или задать размер шрифта типа 7,17 пунктов. Хотя источником проблемы обычно служит небрежно сделанный шрифт2 или же шрифт, преобразованный в момент вывода из формата True Type, это не освобождает язык PostScript от ответственности. Шрифт, созданный на языке PostScript, не должен «валиться» в интерпретаторе этого языка ни при каких обстоятельствах — или должен давать ошибку на любом интерпретаторе. К сожалению, в реальных условиях две «слишком близко» расположенные точки в контуре символа сливаются в одну при низких разрешениях и порождают самопересекающийся контур при высоких. В случае с символом шрифта самопересекающаяся кривая Безье приводит к «краху» интерпретатора, в случае плохого обтравочного контура (clipping path) в Photoshop EPS (например, у обтравки, сделанной c помощью «волшебной палочки») результатом может стать пересечение изображения «непонятно откуда взявшейся» тонкой линией. Резюмируем: кривая Безье при слишком близко расположенных опорных точках становится чрезмерно чувствительной к погрешностям округления, что порождает искажения формы контура при изменении разрешения.
Ну и последний недостаток — не столько самого PostScript, сколько способа записи в него. Основной принцип создания языка, если вы помните, — избавление компьютера от лишней работы. Поэтому, даже если изображения на экране перекрываются, подавляющее большинство программ запишет в PostScript все иллюстрации целиком, взвалив на растровый процессор труд удаления невидимой части. С одной стороны, это хорошо, поскольку сохраняет теоретическую возможность «открыть» PostScript-файл для редактирования. С другой стороны, это приводит к явной избыточности за счет хранения невидимых частей изображения. Такая избыточность, в свою очередь, приводит к потерям времени на растрирование, а на маломощных растровых процессорах — к краху интерпретатора из-за переполнения стека (попросту, нехватки памяти).
Еще один минус PostScript — его «нечитаемость». Для того чтобы увидеть ожидаемый результат вывода до появления пленки из проявочной машины, оператору приходится либо растрировать PostScript какой-либо вспомогательной программой типа Acrobat Distiller или Transverter Pro, сохраняя известную долю сомнения в достоверности результата проверки, либо просматривать «preview» на RIP, тратя драгоценное время выводного устройства. Из-за невозможности «непосредственно» посмотреть PostScript-файл сервисные бюро вынуждены требовать с заказчика бумажные распечатки, создавая дополнительные трудности для клиентов.
Отметим, что перечисленные недостатки не являются чем-либо фатальным. Идеальный мир недостижим, поэтому людям приходится работать в мире реальным. Большая часть проблем ярко проявляется в качестве «детских болезней» при освоении новых технологий (соответствующие списки «известных ошибок и ограничений» существуют для любой программы) и постепенно сходит «на нет» по мере накопления опыта. Реальные вероятности ошибок и вопросов, непосредственно связанных с ограничениями и недостатками языка PostScript, в отработанных технологических цепочках составляют доли процента — ничто по сравнению с ошибками, происходящими из-за, например, «человеческого фактора».
Говорить о преимуществах PDF легко и просто — для этого нужно просто зайти на один из Internet-сайтов, посвященных тематике PDF (www.pdfzone.com , www.planetpdf.com , наконец, www.adobe.com), и воспользоваться бесконечно повторяющимися фразами. Сведем их к краткому резюме. PDF лучше, потому что он «быстрее, компактнее, стабильнее, надежнее, удобнее и универсальнее, чем PostScript. В отличие от PostScript, PDF можно просмотреть. Наконец, PDF является иерархическим структурированным форматом данных, в отличие от PostScript, который является однопроходным языком программирования». Два последних факта, в действительности, являются определяющими все остальные (в том числе, истинность процитированных утверждений). Итак, разговор о преимуществах PDF начат несколько преждевременно. Прежде всего, необходимо выяснить:
В отличие от PostScript, создававшегося как язык управления принтером (идея использовать PostScript как формат выводного файла для его передачи в сервисное бюро появилась значительно позже), PDF — это переносимый формат документов (portable document format), созданный Adobe как средство межплатформенного обмена данными. Хотя существует масса способов передать документ, например, между Windows и Mac OS, Adobe PDF предлагает наиболее элегантное решение. Формат не накладывает никаких ограничений на внешний вид документа — текст, векторная и растровая графика могут быть объединены произвольным образом. Реализуется принцип «все мое ношу с собой» — для просмотра PDF-файла не нужно ничего, кроме самого файла и бесплатной программы Acrobat Reader. Таким образом, изначально PostScript создавался как интерпретируемый «на лету» язык передачи данных на вывод, PDF — как формат хранения данных в виде, «читабельном» на любой компьютерной платформе.
PostScript содержит все данные, необходимые для создания изображения и, следовательно, может быть преобразован в PDF. Обратное, вообще говоря, неверно — информации для вывода на экран требуется гораздо меньше в силу малого разрешения дисплея, и файлы PDF, как правило, содержат полутоновую графику с пониженным разрешением. Прекрасно подходящий для распространения электронной информации и web-публикации, PDF стал фактическим стандартом в этих областях, не затрагивая лидерства PostScript в допечатных технологиях.
Как уже говорилось, PDF создавался как формат электронного документа. Необходимость быстрого перемещения по страницам и объектам документа обусловила иерархическую структуру данных PDF. В начале файла находится оглавление, показывающее где и какие объекты расположены в файле, затем идут сами данные. Для того, чтобы что-либо делать с PDF-файлом, его нужно иметь целиком, поскольку фрагмент данных, который понадобится первым, может находиться в любой части файла — в том числе и в самом конце.
Это отличие является единственным принципиальным отличием между PDF и PostScript. В обоих языках для описания контуров символов в шрифте и в векторной графике используются кривые Безье; в обоих присутствует один и тот же внутренний формат шрифта и примерно одинаковый набор операций над геометрическими примитивами. Естественно, что с определенного момента фирма Adobe начала работать над объединением двух форматов в один. Поэтому разговоры о «замене» PostScript’а PDF’ом звучат несколько странно — PostScript 3 позволяет интерпретировать PDF, тогда как формат PDF 1.3 включает в себя основные команды PostScript по управлению параметрами цветоделения и другие типично «полиграфические» инструкции — так что на что мы собираемся заменить? Для еще большего усиления сходства фирма Adobe создала «встраиваемую» версию формата PDF — embedded PDF, предназначенный для использования наравне с EPS или вместо него.
Итак, обобщим: PostScript является языком программирования, оперирующим графическими данными, тогда как PDF — форматом хранения графических данных, включающим описание, позволяющее связать их в единый документ. Все остальные различия являются следствиями. Давайте рассмотрим их подробнее.
PDF быстрее, чем PostScript. Имеется в виду два факта. Во-первых, поскольку PDF компактнее, он быстрее передается по сети и быстрее обрабатывается (примерно пропорционально разнице в объемах). Кажется очевидным и справедливым — в той мере, в какой PDF действительно компактнее. Во-вторых, PDF быстрее в силу удобного доступа к объектам; но только для случая, когда нужно просматривать документ в произвольном порядке и выбирать отдельные объекты. Интерпретатору PostScript не приходится это делать, поскольку каждый объект появляется в последовательном PostScript-файле именно в тот момент, когда его нужно обработать. Поэтому для целей растрирования и вывода иерархическая организация PDF не дает реального выигрыша в быстродействии.
Более того, использование PDF для вывода предполагает, что файл должен быть загружен в растровый процессор целиком еще до начала обработки. Если учесть, что подавляющее большинство RIP лазерных экспонирующих устройств способны обрабатывать PostScript c той же скоростью, с какой рабочая станция с программой верстки генерирует поток данных, становится не совсем понятным, что мы хотим сэкономить. Время от завершения создания PostScript до завершения его интерпретации практически равно нулю, тогда как от момента завершения записи PDF на RIP до завершения его обработки все же требуется несколько секунд.
PDF компактнее. Это, как ни странно, часто бывает правдой. Типичный пример, который приводят сторонники передовых технологий, выглядит так: исходный PostScript-файл — 150 Мбайт, полученный после обработки Acrobat Distiller документ PDF — 50 Мбайт, полученный из PDF PostScript — 70 Мбайт. Пример показывает радикальную экономию и является достаточно распространенным. С другой стороны, могу привести свой пример. Известно, что полоса A4 при разрешении 300 dpi и 100 % заполнении полутоновым изображением «весит» 30-35 Мбайт. Используя алгоритмы сжатия без потерь типа LZW, это число можно уменьшить, и иногда достаточно сильно, но это к делу не относится. Уменьшить объем переводом в формат PDF тоже не удастся — если параметры перевода предусматривают сохранение качества изображения, значительного сжатия не произойдет.
Многие авторы, пишущие о значительном уменьшении объема файла PDF по сравнению с PostScript забывают указать, что компактность достигается при JPEG-сжатии. Но JPEG — это алгоритм сжатия с потерями, и для качественной полиграфии неприменим или «ограниченно применим». Если потери допустимы, JPEG можно с успехом использовать прямо при верстке — большинство современных RIP PostScript level 2 и все RIP PostScript 3 понимают JPEG-графику внутри PostScript. Так что экономия места за счет использования JPEG-компрессии не является прерогативой формата PDF. Итак, PDF сокращается за счет «выкидывания» из PostScript какой-то бесполезной информации. Какой же?
Создайте в QuarkXPress или Adobe PageMaker пустой файл и сделайте из него PostScript. Получится файл объемом 300-500 Кбайт. Что это? Вспомните, мы говорили об удобстве PostScript — каждая программа записывает набор понятных ей функций в так называемый пролог, «надстраивая» язык наиболее подходящим для нее образом. Эти 300-500 Кбайт и есть пролог, совершенно ненужный ввиду отсутствия полезной информации. PDF не содержит кода — только инструкции размещения для реальных объектов, так что пролог исчезает. PostScript здесь ни при чем — это «ленивые» программы верстки записывают в пролог все подпрограммы, которые могут пригодиться, а не только те, что необходимы реально. Сам PDF, кстати, при выводе в PostScript впишет туда собственный пролог — хотя и небольшой.
Другой источник сокращения объема — удаление невидимых объектов. Acrobat Distiller старается оправдать свое название, вычищая из PostScript-кода все то, что не может быть увидено. Чем больше верстальщик использовал маскирование и наложение объектов, тем больше будет экономия от перевода в PDF.
Наконец, сам код PostScript-программы занимает несколько больший объем, чем двоичные коды размещения в PDF. Хотя на фоне размера полутоновых иллюстраций этот код занимает очень скромное место, в случае преобладания на полосе текстовой информации разница в объемах становится ощутимой.
Если не говорить о «патологических» случаях с наложением больших полутоновых иллюстраций, суммарное сокращение размеров PDF по отношению к PostScript достигает 2-3—кратного на книжно-газетной верстке и падает практически до «один к одному» на чисто иллюстративных полосах. Если же говорить о «патологических» случаях, можно привести и контрпример. Программист, знающий PostScript, без напряжения напишет код в 2-3 Кбайт, генерирующий сложный рисунок наподобие гильоширной сетки на ценных бумагах. После «дистилляции» в PDF такой код в размерах не уменьшится, а увеличится — причем в несколько (а то и в несколько десятков) раз. Поскольку PDF не может содержать инструкций типа «повторить со сдвигом», Distiller будет вынужден «раскрыть» все циклы в последовательности однотипных команд.
PDF стабильнее и надежнее, чем PostScript. Действительно, как было сказано выше, ряд проблем PostScript связан с неоднозначной интерпретацией программ на разных растровых процессорах и при разных параметрах (в первую очередь, разрешении растровых объектов). Поскольку PDF-файл не является программой, в нем нечему, например, «зациклиться». Соответственно, если какой-либо фрагмент PostScript-кода ошибочен — соответствующий PDF либо просто не может быть создан, либо ошибочный фрагмент будет каким-то образом исправлен. Иными словами, файл в формате PDF принципиально не может содержать некоторых ошибок, которые теоретически может содержать программа на языке PostScript.
Преимущество, безусловно, есть, и преимущество важное. Не нужно только его абсолютизировать. Во-первых, грамотно сделанный из грамотно подготовленной публикации PostScript ошибок тоже почти никогда не содержит. Во-вторых, если в верстке использован «кривой» шрифт или неряшливо сделанная обтравка, построение сплайнов Безье на высоком разрешении при плохо обусловленных исходных данных даст тот же самый результат — и в PDF, и в PostScript контуры символов шрифта и векторных объектов задаются абсолютно одинаково. Поэтому, если какой-либо шрифт или EPS сбоит при выводе через PostScript, шансов на исправление ситуации с помощью PDF практически нет. Исключения составляют явные ошибки PostScript-кодирования — но такие ошибки, к счастью, достаточно редки.
Система подстановки шрифтов в PostScript и PDF работает тоже почти одинаково — PDF может найти правильный шрифт в операционной системе рабочей станции и показать верстку на экране правильно, хотя внутри файла нужного шрифта может и не быть. И в-третьих, из явно ошибочного PostScript (или из верстки, содержащей явно ошибочный EPS) никакого PDF получить не удастся вообще. Конечно, не будет потерь времени и материалов на вывод явного брака — но получению положительного результата это не способствует.
PDF удобнее, чем PostScript. В первую очередь, за счет того, что его можно мгновенно просмотреть на любой рабочей станции. При отсутствии функции предварительного просмотра на растровом процессоре (или при нежелании тратить время RIP на предпросмотр) это преимущество трудно переоценить. Нужно только не забывать, что сам факт успешного прочтения и просмотра PDF на экране (в отличие от просмотра отрастрированных карт битов на RIP) не дает стопроцентной гарантии успешного вывода. Еще одно удобство — иерархическая организация позволяет программам спуска полос быстрее извлекать из документа отдельные страницы, чем это делается при последовательном просмотре PostScript-файла. При необходимости внести минимальную текстовую правку это можно сделать прямо в формате PDF, значительно сокращая петлю коррекции ошибок.
PDF универсальнее, чем PostScript. Действительно, универсальнее — в том смысле, что один и тот же файл можно открыть и просмотреть на разных платформах. Не на всех, но на Windows, Mac OS и ходовых версиях Unix — можно, а остальные платформы на полиграфических рабочих станциях — редкий гость. Универсальнее PDF и тем, что для Web-публикаций, распространения электронных документов и подготовки печатной версии подходит один и тот же формат (формат, а не файл!). Если для текстового (или почти текстового) документа разницы никакой нет, то любая полутоновая иллюстрация, подготовленная для качественной печати, слишком «тяжела» для издания в Internet и наоборот. Так что термин «универсальность» здесь правильнее использовать в смысле общего инструментария, а не создания файла, одинаково пригодного на все случаи жизни.
Иногда универсальность PDF преподносят на примере употребления одного файла для вывода на различные устройства (CtP, фотоформу, цифровую цветопробу и т. д.). Теоретически, такая возможность существует. Что касается практики… Для вывода на цифровую цветопробу типа Digital Cromalin или Rainbow документ должен быть цветным (не цветоделенным). Однако такой документ, например, гарантированно не может содержать установок треппинга программы QuarkXPress — ни в PostScript, ни в PDF. Единственный способ сохранить треппинг при выводе из Quark — цветоделить в Quark. Конечно, этот пример — частность. К сожалению, таких частностей довольно много, и принцип «один файл на все случаи жизни» сводится не к замене PostScript на PDF, а к замене файла программы верстки на PDF, из которого можно сделать PostScript для любого выводного устройства — и то, с учетом ряда оговорок. А если вы использовали в верстке растровую иллюстрацию с разрешением 2400 dpi3, то ни с каким другим разрешением вы свою верстку вообще не выведете (или выведете, но с муаром) — ни через PDF, ни через PostScript, ни через TIFF. Какая уж тут универсальность.
PDF удобнее как формат передачи данных между заказчиком и исполнителем, поскольку может быть быстро просмотрен на любом компьютере с помощью бесплатной программы Acrobat Reader. Для документов с явным преобладанием текста и векторной графики формат PDF, как правило, обеспечивает заметное сокращение объема файла (с соответствующим сокращением времени пересылки по сети и т. д.). Благодаря отсутствию интерпретируемого кода, использование формата PDF несколько повышает вероятность успешного вывода «твердой копии», особенно если публикация или ее часть подготовлена в программах, склонных к неосторожному обращению с языком PostScript. Для документов, не содержащих полутоновой графики высокого разрешения, один и тот же PDF-файл может быть использован для разных видов публикации (печать, Web, электронная книга и т. д.).
Итак, PDF имеет определенные плюсы по сравнению с традиционным PostScript. Осталось выяснить, как их реализовать.
В «классической» PostScript-технологии файл формата PostScript используется как универсальный посредник между программами верстки, с одной стороны, и любыми выводными устройствами (точнее, их растровыми процессорами), с другой. Независимо от того, печатается документ непосредственно на сетевом принтере или записывается в файл для последующей передачи в сервисное бюро, задействован один и тот же формат данных. Содержимое может и должно меняться в зависимости от устройства, для которого PostScript предназначен.
PDF-технология предполагает, что PostScript полностью или частично заменяется на PDF. Практически это означает, что программа верстки должна каким-то образом создать PDF-файл, который затем нужно вывести на тех или иных устройствах.
Существует четыре принципиальных возможности:
Первые два пути достаточно близки и позволяют получить PDF-эквивалент исходного документа. Именно документа — при сохранении или экспорте в формат PDF обычно не предусматривается возможность задания параметров цветоделения, крестов совмещения, обрезных меток и вообще всего того, что принято указывать при печати в PostScript.
Третий путь для подготовки документов к печати подходит крайне ограниченно. Adobe PDF Writer не умеет правильно обрабатывать помещенные в верстку иллюстрации в формате EPS и не всегда справляется с русифицированными TrueType-шрифтами в Windows — думается, можно не продолжать. Хотя идея использовать драйвер печати, дающий на выходе готовый PDF-файл, крайне привлекательна, реализация ее пока остается делом будущего.
Четвертый путь позволяет получить PDF, точно соответствующий желаемому результату — с обрезными метками, «вылетами», цветоделенный (если необходимо) и т. д. Если технология предусматривает in-RIP цветоделение или OPI-подстановку, профили ICC и комментарии OPI (Scitex APR) могут быть сохранены при переводе в PDF. Одно маленькое «но» — объем работы значительно увеличивается. Помимо подготовки PostScript-файла (на чем вы ничего не выигрываете и не проигрываете), его придется обработать Acrobat Distiller. По существу, Distiller представляет собой настоящий растровый процессор. Помимо того, что он (в отличие от Acrobat Reader и PostScript-драйверов) не является бесплатным, запускаться он будет не на мощном компьютере, на котором обычно работают RIP-выводные устройства, а на обычной рабочей станции. Иными словами, это дополнительные деньги (к счастью, небольшие) и довольно значительное дополнительное время.
Любой RIP PostScript 3 понимает PDF как разрешенный входной формат — при условии, что в PDF есть все необходимое для вывода (если PDF сделан из PostScript или RIP может сам проставить все необходимые элементы оформления). Если же выводное устройство имеет RIP level 2 или даже 1, а также для PDF-файлов, сохраненных без параметров цветоделения или меток печати (даже если RIP может создать свои приводочные кресты, иллюстрации «навылет», например, будут все равно обрезаны по формату документа), единственный доступный путь… вновь создать PostScript, «напечатав» его из Acrobat Reader.
В традиционной PostScript-технологии заказчик (рекламное агентство или издательство) мог передать на вывод (в сервис-бюро или типографию) либо документ, то есть файл программы верстки со всеми причитающимися иллюстрациями и шрифтами, либо готовый PostScript. В первом случае PostScript делает исполнитель, во втором — заказчик. С появлением PDF появляется еще одна возможность — передать PDF-файл. Точнее, не одна, а две возможности: вы можете передать цветной PDF вместо исходного документа, предполагая, что исполнитель все равно будет создавать из него PostScript; или же передать на вывод «готовый» PDF, который (при наличии RIP PostScript 3) можно непосредственно отправить на выводное устройство. По технологии оба варианта заметно различаются, как в глазах заказчика, так и в глазах исполнителя. Давайте кратко взвесим имеющиеся «за» и «против».
Передавая документ PDF вместо файла программы верстки, вы получаете следующие преимущества:
Но есть и недостатки:
Передавая полностью готовый к выводу PDF вместо PostScript, вы приобретаете возможность посмотреть, что у вас получится (хоть и без стопроцентной уверенности) и сокращаете размер файла. Вы проигрываете время на работу Acrobat Distiller и другие затраты, связанные с «перегонкой» PostScript в PDF, а также проигрываете в цене (особенно, если у исполнителя RIP level 1 или 2).
Принимая PDF вместо документа программы верстки, вы существенно сокращаете время работы по приему. Поскольку возможности что-то починить (нецветоделенную иллюстрацию, потерянный шрифт и т. д.) в PDF практически отсутствуют, прием работы сводится к автоматизированной предварительной проверке (конечно, если вы ее используете4).
Вы избавляетесь от необходимости устанавливать шрифты заказчика и разыскивать единственный во всем репроцентре компьютер, на котором установлена экзотическая программа, в которой документ сверстан. Вы, так же как и заказчик, со своей стороны проигрываете на удлинении петли коррекции ошибок. Необходимость замены шрифта вынуждает вас вернуть работу, вместо того чтобы, затратив 15 минут, проявить профессионализм, сэкономить свое время и время клиента, а также (возможно) заработать дополнительные деньги.
Принимая для вывода готовый PDF вместо столь же готового PostScript вы выигрываете возможность посмотреть на него на любом свободном компьютере, прежде чем отправить на вывод. Хотя это и не дает такой уверенности, как просмотр на RIP, это лучше, чем выводить без просмотра совсем. Это так же не отменяет требование предоставить бумажный макет — хотя бы потому, что бумажный макет заказчик может (и должен) подписать.
Проигрываете вы… Если выводное устройство оснащено RIP PostScript 3, вы ничего не проигрываете. Если же «продвинутого» интерпретатора нет, PDF приходится превращать обратно в PostScript, что по времени мало отличается от генерации оригинального PostScript из программы верстки.
Если репроцентр оказывает дополнительные услуги (спуск полос, треппинг, OPI-подстановка и другие операции, выполняемые в специализированных программах), также могут возникнуть проблемы. Инерционность производителей достаточно велика, и варианты модернизации или обновления с возможностью обработки PDF-файлов наряду с PostScript могут быть недоступны. А если и доступны — готов ли ваш финдиректор выложить 2-4 тысячи (не рублей) за то, чтобы научить OPI-сервер переваривать PDF?
Использование файлов PDF вместо исходных документов оправдано: при работе в мало распространенных программах верстки, при необходимости передавать документы с преобладанием текста (книги, газеты) по низкоскоростным каналам, а также в тех случаях, когда технологический процесс исполнителя не предусматривает работу с разнородными исходными документами (принимают либо PostScript, либо PDF). Использование файлов PDF вместо PostScript оправдано при наличии у исполнителя RIP PostScript 3 и при условии, что вы готовы платить временем работы Acrobat Distiller за возможность посмотреть на экране ожидаемый результат вывода (да и то без гарантий). Ситуация может (и, видимо, должна) измениться с появлением PDF Writer, являющегося полноценной заменой PostScript-драйвера печати.
Eсть ли альтернативы? Вопрос, конечно, интересный. Если говорить о стратегическом противостоянии PostScript versus — PDF, то нет. Adobe провозгласила курс на переход к PDF — следовательно, по мере «вымирания» устаревших RIP и с появлением полноценного PDF Writer, заменяющего собой PostScript-драйвер печати, PDF плавно, но решительно займет место PostScript. Основной выигрыш получат (и уже получают) редакции, пересылающие верстку по телефону в другие города. Все остальные получат выигрыш в удобстве — за счет возможности предварительного просмотра и некоторого снижения вероятности сбоев. Того, что вправе ожидать пользователи от «стратегической альтернативы», не будет. Исполнители не избавятся от необходимости предвыводного контроля всеми доступными средствами, а заказчики не получат гарантий успешного вывода. То есть будет не качественно иная, а косметически подправленная технология. Была хорошая — будет чуть лучше.
Иными словами, есть ли способ получить, например, гарантированный вывод? С этой точки зрения альтернативы существуют. И эти альтернативы ориентированы не на газетную верстку, а на цветные издания высокого качества — те самые, в которых А4 «весит» 20-30 Мбайт.
Вспомним, что для получения PDF самый ходовой путь сегодня — отрастрировать PostScript с помощью Acrobat Distiller. Distiller представляет собой самый настоящий интерпретатор PostScript — только результат интерпретации вновь записывается в векторном формате. Если уж мы все равно вынуждены интерпретировать PostScript, почему не довести эту работу до конца и не послать на вывод готовые карты битов?
Конечно, посылать карты битов высокого разрешения довольно накладно и в плане стоимости RIP, и в плане жесткой привязки к определенному оборудованию. Многие думают, что самым страшным является увеличение объема файлов. В действительности сжатая простейшими алгоритмами карта битов высокого разрешения для полностью занятой иллюстрациями полосы формата A4 занимает 30-50 Мбайт. Конечно, для строго текстовых полос проигрыш больше.
Разумеется, поставить в издательстве Harlequin RIP с определенным драйвером означает намертво привязаться к единственному типу выводного устройства. К счастью, многие производители RIP предлагают возможность растрирования в промежуточные форматы, которые могут быть выведены на любом «совместимом» устройстве со стопроцентной гарантией (можете себе представить, чтобы TIFF открывался в Photoshop и не выводился на фотонабор?).
Самым ходовым форматом для передачи отрастрированных карт битов между растровыми процессорами является TIFF-IT/P1, расширяющий формат TIFF для данной специфической задачи. Недостаток: необходимость иметь RIP, «понимающий» TIFF-IT (для большинства современных RIP это довольно дорогая опция). С растрированием PostScript в TIFF-IT ситуация улучшается достаточно быстро. По мере распространения технологии TIFF-IT опции преобразования в TIFF-IT анонсируются не только у RIP ведущих производителей, но и у программных RIP типа Transverter Pro и даже в качестве расширений к программам верстки.
Другое универсальное решение предлагает CreoScitex с технологией RipOnce. Растровый процессор Brisque переводит PostScript в две карты битов: высокого разрешения new LW и низкого new CT. Эту пару файлов можно вывести на любое устройство Scitex (Dolev, Lotem, Iris), Creo Trendsetter или Kodak Approval. Единственным ограничением является разрешение LW — вывод на устройстве с некратным, особенно близким разрешением (типа 2540 dpi / 2400 dpi) чреват появлением муара. Понижение разрешения в целое число раз (2400 dpi до 1200 dpi для Appoval или до 300 dpi для Iris) допустимо и осуществляется в процессе вывода5.
Для вывода на «несовместимых» устройствах предусмотрена опция, «сворачивающая» пару CT/LW в так называемый «плоский» PostScript. Плоский — поскольку наложение изображений исключено при растрировании, а значит и объем приближается к минимально возможному. Поскольку векторная составляющая PostScript в таком файле отсутствует (напомню, что LW, хоть и называется line work, в действительности представляет собой карту битов), «плоский» PostScript, также как и TIFF-IT/P1, гарантированно выводится на любом устройстве подходящего разрешения.
Близкая по идее к Scitex технология предлагается Heidelberg: вместо CT/LW используется внутренний формат Delta List. Растровый процессор израильской фирмы Shira способен растрировать в обычный TIFF для цветопробы или глубокой печати, в TIFF-IT для выводных устройств высокого разрешения, или в плоский PostScript, если опцион TIFF-IT недоступен на выбранном устройстве вывода.
Формат файла PDF представляет собой быстро развивающуюся и относительно недорогую прямую замену PostScript в допечатной технологии. Являясь непосредственным родственником PostScript, формат PDF сохраняет ряд его принципиальных («генетических») недостатков, предоставляя вместе с тем ряд преимуществ с точки зрения пользователя. Более дорогой, но обладающей гарантированной надежностью альтернативной технологией является передача на вывод вместо векторных растрированных bitmap-форматов.
Алексей Моисеев — ведущий инженер-программист, PTC, Бостон, шт. Массачусетс. С ним можно связаться по электронной почте amoisseev@ptc.com.
Хотя и до PostScript были языки программирования с развитой графикой, использование их было невозможно из-за проблемы «просмотра вперед». Практически любой язык для выполнения команд перехода или цикла должен просмотреть последующий текст программы для того, чтобы найти метку перехода или конец цикла. Авторы PostScript исходили из жесткого требования — каждая команда исполняется немедленно после ее получения и (при необходимости последующего использования) однократно переводится во внутренний формат. Такой подход, с одной стороны, открывает возможность интерпретации программы «на лету» по мере поступления информации от компьютера, не дожидаясь прихода всего файла (который может быть достаточно большим), минимизируя, тем самым, время ожидания результатов вывода. С другой стороны, отсутствие повторного просмотра кода делает работу самого интерпретатора более эффективной. Цена, которую за это пришлось заплатить — своеобразный вид программы. Если инструкция «вычислить значение переменной А как сумму числа 2 и значения переменной В» в подавляющем большинстве языков программирования выглядит как «А = 2 + В», PostScript-код выглядит примерно как «2 знач.В + перем.А =». Такой способ записи информации носит название «обратная нотация» или «обратная польская запись» и исполняется по схеме:
занести в стек* число
2;
занести в стек значение переменной В;
сложить два числа в вершине
стека;
поместить адрес переменной А в стек;
переместить второе с вершины
стека число по адресу, хранящемуся на вершине стека.
Поскольку принцип обратной нотации является основным для понимания принципов PostScript, остановимся на нем чуть подробнее (программисты могут пропустить до конца абзаца). Все команды PostScript либо исполняются немедленно (если все данные для ее исполнения готовы), либо загружают информацию в специальную память — стек, подготавливая ее для обработки последующими командами. Типичная PostScript-программа загружает в стек достаточно много информации и затем несколькими командами вызывает формирование желаемого результата. Последней командой PostScript-программы является инструкция showpage, вызывающая «отрисовку» окончательно сформированного в вершине стека изображения на физическом носителе.
Принцип обратной польской записи пытались применить в самых разных областях — в частности, для программируемых калькуляторов, но ввиду его непривычности для человеческого мышления широкого применения эта технология не получила. Однако для вывода графической информации PostScript оказался удачной находкой. Программе, выводящей информацию на PostScript-принтер, нет необходимости формировать длинную последовательность команд на «чуждом» ей языке. Достаточно один раз определить набор подходящих сокращений и подпрограмм (соответствующая вступительная часть PostScript-кода называется прологом). Дальнейшая работа фактически сводится к передаче уже готовых внутренних данных программы на выводное устройство.
PostScript позволил эффективно решить такую непростую задачу, как обтравка (clipping) изображений. Традиционные векторные языки управления принтером для этой цели практически не годились. Единственный, но не всегда применимый и крайне неэффективный путь состоит в том, чтобы «залить» лишнюю часть изображения цветом фона. Соответствующую задачу в PostScript можно решить в три простых действия: 1. Создать изображение. 2. Создать контур. 3. Обрезать изображение по контуру. Поскольку в процессе работы PostScript хранит все промежуточные данные в стеках, а не в завершенной карте битов, формирование картинки с криволинейными краями проблем не вызывает.
* Стек — область памяти, организованная по принципу «последним вошел, первым вышел» (LIFO – last in, first out). Помещение в стек нового значения «проталкивает» предшествующие в глубину; выполнение операции «снимает» операнды с вершины стека и замещает их результатом. — Прим. автора.
Возьмите CorelDRAW ранней (4-5) версии. Создайте объект размером 0,1 дюйма с градиентной заливкой от черного до белого. Не забудьте поставить 256 градаций для градиентов. Замаскируйте объект чем-либо сверху и создайте довольно большой простой объект (допустим, черный квадрат). Сохраните в EPS. Поставьте EPS на полосу в программе верстки как импортированную графику. Поставьте масштаб изображения 10 %. Сделайте PostScript на 2540 или 2400 dpi и отправьте на RIP Adobe level 2 (или 1). RIP зависнет или выдаст сообщение об ошибке. Ни один оператор ничего не заподозрит и ни о чем не догадается, пока не откроет EPS и не разберет его на мелкие составляющие.
Почему? Очень просто. Умная программа CorelDRAW запишет градиент в EPS (хотя он и не виден на экране), используя преимущества PostScript как языка программирования. Вместо рисования 256 прямоугольников будет создан цикл вида:
{
нарисовать прямоугольник;
изменить цвет;
изменить положение;
повторять, пока не дойдешь до конца объекта
}.
Формально цикл совершенно правилен — пока мы не начинаем вычислять координаты в целых числах, как это делают очень многие RIP. После масштабирования 1:10 шаг становится меньше, чем половина пиксела, то есть в целочисленном представлении становится равным нулю. В результате цикл никогда не дойдет до конца объекта — RIP «зациклится».
1 Чисто теоретически, можно использовать и другие два способа. Но для этого необходимо получить в сервис-бюро экранные версии шрифтов, установленных в RIP, и использовать в верстке их и только их. В российскую действительность эта технология вписывается плохо — хотя бы потому, что ни один импортный RIP не содержит кириллицу в своем комплекте шрифтов. — Прим. автора.
2 Справедливости ради отметим, что с лицензионно-чистыми библиотеками шрифтов после 1997 года в России заметных проблем не возникало, чего нельзя до сих пор сказать о доморощенных поделках. — Прим. автора.
3 Такие иллюстрации, как правило, являются результатом сканирования готовых цветоделенных фотоформ, например, для последующего вывода на CtP. Для успешного вывода такое copydot-сканирование всегда производится с разрешением, равным разрешению вывода. — Прим. автора.
4 Практически все производители программ для «предполетного контроля» PostScript-файлов и файлов программ верстки делают соответствующие версии для PDF. — Прим. автора.
5 По информации, полученной от компании «Амос». — Прим. автора.