Пакет макетирования страниц идеологически "не должен" вмешиваться в структуру данных помещаемых в него файлов. Программистам, вероятно, знакомо понятие "инкапсуляция", имеющее непосредственное отношение к объектно-ориентированному подходу в программировании той или иной задачи. Один из вариантов перевода слова "инкапсуляция" звучит примерно как "сокрытие" и определяет то, что оболочка, использующая инкапсулированный объект, обращается с ним как с "вещью в себе", и может не анализировать его внутреннюю структуру для эффективной работы с ним. Работа же с объектом проводится через ряд заранее определенных методов, стандартизированных для всех объектов подобного рода (заранее прошу прощения у читателей-программистов за возможную неточную трактовку их термина, так как здесь он применяется в несколько другом контексте). Применительно к графике, и в частности, к QxP, замечу, что идеологически принцип работы пакета построен на схожем принципе - программа работает с помещенными объектами других программ, модифицируя только их основные общедоступные параметры (размер, угол наклона, поворот и т.д.). Треппинг же при этом для инкуапсулированных (сокрытых) в связанном файле объектов не проводится.
С этим связана одна неявная проблема, когда в верстку помещается графический объект, поверх которого распологается цветной текст или цветной графический элемент, созданный средствами QxP. Рассмотрим пример.
|
| Рисунок 5. Установки треппинга на Indeterminate и trap information
|
Из рисунка видно, что мы поместили в верстку один графический файл с белым фоном и создали два одинаковых текстовых блока, один из которых касается рисунка, а второй - не касается. С точки зрения любого здравомыслящего препресс - инженера, треппинг не нужен ни в первом, ни во втором случае. Практически же, QxP не в состоянии определить, пересекается ли текстовый блок, размещенный над графическим блоком, с цветной или белой областью, так как цвет этой области описан не средствами QxP, а определяется самим связанным файлом. Для описания такого неопределенного цвета (и соответственного треппинга в нем) разработчики ввели специальный термин Indeterminate, имеющийся в диалоговом окне настроек треппинга в QxP (Trapping options), которое было приведено выше.
Как поведет себя QxP в этой ситуации, также видно из рисунка. Для текстового блока, пересекающегося с графическим блоком, будет проведено автоматическое расширение для компенсации возможного несовмещения. Для нижнего текстового блока такого не произойдет. Это приведет к тому, что две одинаковые строчки текста будут отпечатаны с разной степенью визуальной толщины линий начертания символов. Визуально, верхний текст будет похож на полужирное начертание нижнего, особенно при значительных значениях треппинга, установленных в поле Indeterminate.
Кстати, если бы для графического изображения был бы построен обтравочный контур (clipping path), то такого расширения не произошло бы, так как QxP в этом случае знает четкие границы изображения - где кончается рисунок и начинается незапечатанная бумага. Единственное требование в этом случае, чтобы текстовый блок был обязательно размещен в пределах той части рисунка, которую маскирует наш обтравочный контур.
Что здесь можно порекомендовать? Есть два практических выхода. Первый, вполне разумный, предусматривает установку в поле Indeterminate значения 0 (фактическое запрещение треппинга). Это приведет к глобальной отмене треппинга по всем элементам, подобным тем, которые были описаны выше. Затем дизайнер сможет вручную по всей публикации добавить необходимый треппинг там, где это будет необходимо (с помощью панели Trap Information). Это обеспечивает наилучшее качество треппинга, однако, достаточно затруднительно само по себе. Второй выход предусматривает то, что вы оставите в поле Indeterminate значение по умолчанию, и будете надеяться, что ситуаций, подобной вышеприведенной, в Вашей верстке не произойдет.
