Ответ: Треппинг ин-рип и просто так
Thx, сообразил. Хороший повод подумать на досуге./Alexander сказал(а):
Треппинг ин-рип и просто так
- Автор темы niki81
- Дата начала
- Статус
Ответ: Треппинг ин-рип и просто так
Виноват, сразу не доехал (молодой, но несообразительный огранизм). На завтрак у моего РИПа (он еще не знает) будет Ваш "Test APPE IRT with Transparency.pdf". По идее, результат будет положительный во всех случаях. С учетом, конечно, limitation'а механизмов треппинга pdf2pdf Creo/Heidelberg. Э-ээ, я вообще-то никак не аффилирован с Кодаком и его секретамиsabos сказал(а):Коллега, я попытался. Но увы, я уже не тот молодой и сообразительный организм, что в молодости, я не смог увидеть четкий ответ - будет ли происходить треппинг например в ситуации path+transparency->image (path+forms+transparency->image). Может уважите тугодума? Или known limitation у Kodak'a - очень страшный секрет?
Значит, так
/Alexander
20 лет на форуме
- Сообщения
- 987
- Реакции
- 660
- Сообщения
- 148
- Реакции
- 201
Ответ: Треппинг ин-рип и просто так
Я надеюсь уважаемый Олл меня простит, но позволю себе небольшое замечание (скорее всего я рискую повторить слова ув. Sabos):
RIP - это ведь растровый процессор, основная задача которого сгенерировать растр (bitmaps) - ведь так?
А различные решения, позволяющие либо внедрить в PDF некий код, которым будет руководствоваться RIP при проведении операции треппинга, либо сгенерировать треппинг физически, добавлением новых векторных объектов (каких бы-то ни было – форм, масок, дополнительных слоев и т.д.) RIPом по сути своей не являются, не имея на выходе битовых карт с растром.
С другой стороны (если я не прав – поправьте плиз) RIP рассчитывает треппинг ДО непосредственно операции screening (растеризации). Но при расчете треппинга учитывает параметры растеризации (формы растровых точек и т.д.).
Т.е. можно скатиться до обсуждения абсолютно всего софта, который позволяет так или иначе реализовывать расчет и применение треппинга.
Но тема обсуждения называется In-RIP треппинг, что подразумевает рассмотрение реализации и расчета треппинга непосредственно программой RIP, на основе предопределенных условий, так или иначе переданных RIPу вместе с файлом, который необходимо обработать.
Поэтому я бы предложил продолжить обсуждение темой, более актуальной для «широкого» применения: особенности реализации In-RIP треппинга движком APPE в различных решениях, и другими движками (напр. Global Graphics Harlequin v.8), способными «напрямую» интерпретировать PDF (напр. начиная с версии 1.6) с прозрачностями с высокой степенью получения ожидаемого результата, имея битовые карты на выходе.
Было бы интересно услышать мнения именно на эту тему, ибо в самом ближайшем времени практически все производители ПО будут активнейшим образом продвигать именно APPE-подобные движки-интерпретаторы. Более того рано или поздно CPSI-подобные движки уйдут на свалку (обоснованное IMHO – имеется ввиду обработка «разложенного» PS, напрямую сгенерированного из программ формирования макетов).
Не по теме:
Сорри, может оффтоп: Также, может кто разбирался с механизмом реализации APPE – было бы интересно каким именно образом движок обрабатывает PDF и на каком этапе происходит расчет треппинга.
P.S. На днях будет Apogee PrePress (ApogeeX v.6 (не кандидат релиз, правда) с APPE2, где AGFA пообещала повысить производительность в два раза и заимпрувить отработку треппингов с комбинациями прозрачность+оверпринт (по словам девелоперов - оверпринт они каким-то образом "дорабатывают" сами - до передачи интерпретатору). Если интересно – можем попробовать.
Я надеюсь уважаемый Олл меня простит, но позволю себе небольшое замечание (скорее всего я рискую повторить слова ув. Sabos):
RIP - это ведь растровый процессор, основная задача которого сгенерировать растр (bitmaps) - ведь так?
А различные решения, позволяющие либо внедрить в PDF некий код, которым будет руководствоваться RIP при проведении операции треппинга, либо сгенерировать треппинг физически, добавлением новых векторных объектов (каких бы-то ни было – форм, масок, дополнительных слоев и т.д.) RIPом по сути своей не являются, не имея на выходе битовых карт с растром.
С другой стороны (если я не прав – поправьте плиз) RIP рассчитывает треппинг ДО непосредственно операции screening (растеризации). Но при расчете треппинга учитывает параметры растеризации (формы растровых точек и т.д.).
Т.е. можно скатиться до обсуждения абсолютно всего софта, который позволяет так или иначе реализовывать расчет и применение треппинга.
Но тема обсуждения называется In-RIP треппинг, что подразумевает рассмотрение реализации и расчета треппинга непосредственно программой RIP, на основе предопределенных условий, так или иначе переданных RIPу вместе с файлом, который необходимо обработать.
Поэтому я бы предложил продолжить обсуждение темой, более актуальной для «широкого» применения: особенности реализации In-RIP треппинга движком APPE в различных решениях, и другими движками (напр. Global Graphics Harlequin v.8), способными «напрямую» интерпретировать PDF (напр. начиная с версии 1.6) с прозрачностями с высокой степенью получения ожидаемого результата, имея битовые карты на выходе.
Было бы интересно услышать мнения именно на эту тему, ибо в самом ближайшем времени практически все производители ПО будут активнейшим образом продвигать именно APPE-подобные движки-интерпретаторы. Более того рано или поздно CPSI-подобные движки уйдут на свалку (обоснованное IMHO – имеется ввиду обработка «разложенного» PS, напрямую сгенерированного из программ формирования макетов).
Не по теме:
Сорри, может оффтоп: Также, может кто разбирался с механизмом реализации APPE – было бы интересно каким именно образом движок обрабатывает PDF и на каком этапе происходит расчет треппинга.
P.S. На днях будет Apogee PrePress (ApogeeX
v.6 (не кандидат релиз, правда) с APPE2, где AGFA пообещала повысить производительность в два раза и заимпрувить отработку треппингов с комбинациями прозрачность+оверпринт (по словам девелоперов - оверпринт они каким-то образом "дорабатывают" сами - до передачи интерпретатору). Если интересно – можем попробовать. Ответ: Треппинг ин-рип и просто так
2 1998 /Alexander
Спасибо. Позволю себе небольшой комментарий.
Все четыре варианта справились с простеньким тестом.
Во всех четырех вариантах треп-элемент сильно заметен, не видно работы механизмов понижения заметности (ink reduction, trap color reduction, trap color scaling). Не сомневаюсь в том, что они есть - видимо по-умолчанию отключены.
Удивило то, что ни Prinergy, ни Esko не сделали "скользящего" треппинга на градиенте. Там градиент специально подобран так, что в начале он светлее фона (требуется spread), а в конце темнее (требуется choke). Harlequin sliding выполнил правильно.
Позабавил разнобой с формой треп-элемента. Одинаковый глюк и у Prinergy, и у Esko - похоже одного происхождения наши товарищи.
2 1998 /Alexander
Спасибо. Позволю себе небольшой комментарий.
Все четыре варианта справились с простеньким тестом.
Во всех четырех вариантах треп-элемент сильно заметен, не видно работы механизмов понижения заметности (ink reduction, trap color reduction, trap color scaling). Не сомневаюсь в том, что они есть - видимо по-умолчанию отключены.
Удивило то, что ни Prinergy, ни Esko не сделали "скользящего" треппинга на градиенте. Там градиент специально подобран так, что в начале он светлее фона (требуется spread), а в конце темнее (требуется choke). Harlequin sliding выполнил правильно.
Позабавил разнобой с формой треп-элемента. Одинаковый глюк и у Prinergy, и у Esko - похоже одного происхождения наши товарищи.
/Alexander
20 лет на форуме
- Сообщения
- 987
- Реакции
- 660
Ответ: Треппинг ин-рип и просто так
Естественно есть.
Но упаковщики ink reduction недолюбливают.
Уточню: я приложил результаты для двух вариантов треппинга от Esko: у 4Stage "уши растут" от Artwork (на текущий момент с некоторыми вариациями работает в ArtPro, Nexus, Odystar), ColorStitch -- родной Esko (PackEdge, DeskPack, Backstage).
Оба вариант sliding делать не умеют.
Обещан, правда, в последней версии 4Stage для Odystar, но руки проверить не дошли...
Опять же, консервативные флесо-пользователи на sliding смотрят с сомнением: у меня есть установки растрового треппинга Nexus -- так sliding, не сговариваясь, отключают.
Впрочем, я с настройками сознательно "не шаманил". Сделал все "по умолчанию".
с уважением,
Александр
sabos сказал(а):
Естественно есть.
Но упаковщики ink reduction недолюбливают
. sabos сказал(а):
Уточню: я приложил результаты для двух вариантов треппинга от Esko: у 4Stage "уши растут" от Artwork (на текущий момент с некоторыми вариациями работает в ArtPro, Nexus, Odystar), ColorStitch -- родной Esko (PackEdge, DeskPack, Backstage).
Оба вариант sliding делать не умеют.
Обещан, правда, в последней версии 4Stage для Odystar, но руки проверить не дошли...
Опять же, консервативные флесо-пользователи на sliding смотрят с сомнением: у меня есть установки растрового треппинга Nexus -- так sliding, не сговариваясь, отключают.
Меня больше позабавило, что у программистов Artwork и Esko оказались разные предпочтения в этом вопрсе. Как будно "в пику" друг-другу...sabos сказал(а):
Впрочем, я с настройками сознательно "не шаманил". Сделал все "по умолчанию".
с уважением,
Александр
Ответ: Треппинг ин-рип и просто так
Мне сделали справедливое замечание - увлеклись мол "высокими технологиями", а что простому народу делать?
Результаты треппинга "народными" методами:
1. Встроенный треппинг Indesign. Учтите то, что Indes здесь "сплющил" прозрачности перед треппингом.
2. Heidelberg PDF Toolbox. Ему бы "сплющить" также не помешало.
Мне сделали справедливое замечание - увлеклись мол "высокими технологиями", а что простому народу делать?
Результаты треппинга "народными" методами:
1. Встроенный треппинг Indesign. Учтите то, что Indes здесь "сплющил" прозрачности перед треппингом.
2. Heidelberg PDF Toolbox. Ему бы "сплющить" также не помешало.
Ответ: Треппинг ин-рип и просто так
Prinergy не делает sliding. Я, выше, заранее оговорился об ограниченниях механизмов Creo/Heidelberg (вот уж кто одного происхождения), это один из них. Color reduction я обычно выключаю (если печатня заказывает треппинг 30 мкм, то какой тут reduction), но в моем примере он был включен для максимального подобия другим примерам в теме. И, как можно заметить, Creo/Heidelberg не делают reduction, если один из объектов в паре -- image
Prinergy не делает sliding. Я, выше, заранее оговорился об ограниченниях механизмов Creo/Heidelberg (вот уж кто одного происхождения), это один из них. Color reduction я обычно выключаю (если печатня заказывает треппинг 30 мкм, то какой тут reduction), но в моем примере он был включен для максимального подобия другим примерам в теме. И, как можно заметить, Creo/Heidelberg не делают reduction, если один из объектов в паре -- image
Ответ: Треппинг ин-рип и просто так
.
Color reduction у Heidelberg также мне не нравился. Там очень простенький алгоритм, он часто лажает.
Я PDF Toolbox 4 заставить обрабатывать объекты с прозрачностью не смог - похоже некоторая разница между Creo/Heidelberg все же есть.
Thx, сообразил. Да, у Heidelberg-алгоритма еще со времен DeltaTrap лишь слабенький centerline был для борьбы со скачками.1998 сказал(а):
Маньяки однако1998 сказал(а):
.Color reduction у Heidelberg также мне не нравился. Там очень простенький алгоритм, он часто лажает.
Я PDF Toolbox 4 заставить обрабатывать объекты с прозрачностью не смог - похоже некоторая разница между Creo/Heidelberg все же есть.
- Сообщения
- 4 566
- Реакции
- 2 957
Ответ: Треппинг ин-рип и просто так
ЗЫ. А уж не по битмабу (contone) ли трепит Арлекин? Как-то ему "по-барабану" получаются все прозрачности. Особенно если учесть, что 7-я версия напрямую их держать не обязана.
Может быть Creo предварительно сплющивает? Втихомолку.sabos сказал(а):
ЗЫ. А уж не по битмабу (contone) ли трепит Арлекин? Как-то ему "по-барабану" получаются все прозрачности. Особенно если учесть, что 7-я версия напрямую их держать не обязана.
Ответ: Треппинг ин-рип и просто так
А потом расплющивает взад? Нетрудно увидеть, что transparency 90% сохранился (у form).TRANTOR сказал(а):Может быть Creo предварительно сплющивает?
Треппить внутри битмапа(within image) нереально - результат сильно напоминает блур. Возьми шоп и поэкспериментируй с его trap.TRANTOR сказал(а):
- Сообщения
- 4 566
- Реакции
- 2 957
Ответ: Треппинг ин-рип и просто так
Не, я согласен, что у ФШ трепинг "детский" и с артефактами. Но может у Арлекина "взрослый"? Можно же антиалиасинг не делать, например. И фильтрацией добиться нужного распознавания пар для трепинга. Как говорится, почему нет?
Виноват: поторопился с предположением (так и есть - прозрачность на месте).sabos сказал(а):
Как раз попробовал (вложения).
Не, я согласен, что у ФШ трепинг "детский" и с артефактами. Но может у Арлекина "взрослый"?
Можно же антиалиасинг не делать, например. И фильтрацией добиться нужного распознавания пар для трепинга. Как говорится, почему нет?
/Alexander
20 лет на форуме
- Сообщения
- 987
- Реакции
- 660
Ответ: Треппинг ин-рип и просто так
It depends...
Если изображение "синтетическое" (мультяшное или вроде комикса) -- еще как реально.
Я даже рисовал по запросу пользователей Nexus workflow с подобным треппингом (TIFF на входе и выходе).
Фантазии могут далеко завести.
Первоисточник (http://www.globalgraphics.com/products/trapping/) вполне недвусмысленно сообщает: "The TrapPro object-based ..."
И это утверждение не противоречит тому, как RIP себя ведет при обработке задания и что пишет в логи...
Проверить, какой именнго механизм (объектный, растровый, или гибридный) использует тот или иной алгоритм треппинга можно довольно простыми средствами -- подать на вход заведомо некорректные данные.
с уважением,
Александр
sabos сказал(а):
It depends...
Если изображение "синтетическое" (мультяшное или вроде комикса) -- еще как реально.
Я даже рисовал по запросу пользователей Nexus workflow с подобным треппингом (TIFF на входе и выходе).
TRANTOR сказал(а):Но может у Арлекина "взрослый"?
Фантазии могут далеко завести.
Первоисточник (http://www.globalgraphics.com/products/trapping/) вполне недвусмысленно сообщает: "The TrapPro object-based ..."
И это утверждение не противоречит тому, как RIP себя ведет при обработке задания и что пишет в логи...
Проверить, какой именнго механизм (объектный, растровый, или гибридный) использует тот или иной алгоритм треппинга можно довольно простыми средствами -- подать на вход заведомо некорректные данные.
с уважением,
Александр
- Сообщения
- 87
- Реакции
- 0
Ответ: Треппинг ин-рип и просто так
2 TRANTOR
Вы так убедительно говорили товарищ, что мол пдф тул бокс вычисляет ТВ попиксельно и даже прилагали файл, ну так вот
>Что-то же он по ходу дела для трепинга справа добавляет? И оно разное такое...
А это то же самое, такая же картиночка с градиентом с вычитанным каналом
никакого измерения ND попиксельно PDF toolboks на картинках не производит
еще раз могу повторить это )))
2 TRANTOR
Вы так убедительно говорили товарищ, что мол пдф тул бокс вычисляет ТВ попиксельно и даже прилагали файл, ну так вот
>Что-то же он по ходу дела для трепинга справа добавляет? И оно разное такое...
А это то же самое, такая же картиночка с градиентом с вычитанным каналом
никакого измерения ND попиксельно PDF toolboks на картинках не производит
еще раз могу повторить это )))
- Сообщения
- 87
- Реакции
- 0
Ответ: Треппинг ин-рип и просто так
2 sabos
Вы меня удивляете....
уважаемый сабос (и прочие), пожалуйста посмотрите с чего я начинал тему
Там архивчик на вебфайле лежит , в нем как раз ситуация в которой обьекты покрашенные маджентой лежат на картинке черно-белой клетчатой и градиентной в которой ND меняется ээ попиксельно
Более того там отчетливо виден sliding trap в исполнении MD 7.0
отриповано на 2 движках CPSI и АРРЕ
APPE по сравнению с CPSI неправильно обрабатывает прозрачности (цветовой сдвиг) и пропускает их при треппинге (единственное различие кста)
В архиве еще лежит файл обработанный pdf toolbox, специально чтобы показать беспомощность хейделевского press touch )) по сравнению с ин-рип треппингом
В архиве еще лежит файл не обработанный никак и я очень прошу присутствующих скачать архивчик и проделать-таки тест на sliding trap потому что в тесте которым тут все кидаются нет таки никакого перепада ND, соответственно никакого слайда, то есть это тесть только на наличие треппинга между парами, йо ((
2 sabos
Вы меня удивляете....
sabos сказал(а):
уважаемый сабос (и прочие), пожалуйста посмотрите с чего я начинал тему
Там архивчик на вебфайле лежит , в нем как раз ситуация в которой обьекты покрашенные маджентой лежат на картинке черно-белой клетчатой и градиентной в которой ND меняется ээ попиксельно
Более того там отчетливо виден sliding trap в исполнении MD 7.0
отриповано на 2 движках CPSI и АРРЕ
APPE по сравнению с CPSI неправильно обрабатывает прозрачности (цветовой сдвиг) и пропускает их при треппинге (единственное различие кста)
В архиве еще лежит файл обработанный pdf toolbox, специально чтобы показать беспомощность хейделевского press touch )) по сравнению с ин-рип треппингом
В архиве еще лежит файл не обработанный никак и я очень прошу присутствующих скачать архивчик и проделать-таки тест на sliding trap потому что в тесте которым тут все кидаются нет таки никакого перепада ND, соответственно никакого слайда, то есть это тесть только на наличие треппинга между парами, йо ((
Ответ: Треппинг ин-рип и просто так
. И даже сам применяю. Например в ситуации, когда дилетант присылает макет "из легкого Corel" в виде tiff'а, и вернуть overprint черному тексту (ставшему композитом) уже не представляется возможным.
Переформулирую: "Треппить внутри битмапа в потоке нереально".
В макетах неизбежно попадаются картинки (обычные изображения), для которых такой треппинг смерти подобен, а пояснить треп-алгоритму, что из images обрабатывать, а что нет - непросто. Часто невозможно (например нет поддержки trap zone).
Я догадываюсь/Alexander сказал(а):
. И даже сам применяю. Например в ситуации, когда дилетант присылает макет "из легкого Corel" в виде tiff'а, и вернуть overprint черному тексту (ставшему композитом) уже не представляется возможным.Переформулирую: "Треппить внутри битмапа в потоке нереально".
В макетах неизбежно попадаются картинки (обычные изображения), для которых такой треппинг смерти подобен, а пояснить треп-алгоритму, что из images обрабатывать, а что нет - непросто. Часто невозможно (например нет поддержки trap zone).
/Alexander
20 лет на форуме
- Сообщения
- 987
- Реакции
- 660
Ответ: Треппинг ин-рип и просто так
Согласен абсолютно.
Аминь.
Мои замечания в основном "с упаковочной стороны", где "треппить в потоке" -- стратегия довольно неосмотрительная, по крайней мере без последующей тщательной проверки.
с уважением,
Александр
sabos сказал(а):
Согласен абсолютно.
Аминь.
Мои замечания в основном "с упаковочной стороны", где "треппить в потоке" -- стратегия довольно неосмотрительная, по крайней мере без последующей тщательной проверки.
с уважением,
Александр
- Сообщения
- 148
- Реакции
- 201
Ответ: Треппинг ин-рип и просто так
На мой взгляд вы пытаетесь сравнить несколько несравнимые вещи:
CPSI (PostScript Interpreter): PS in -> bitmap out
APPE (PDF Interpreter): PDF in -> bitmap out
PDF Toolbox (и прочие «псевдо-рипы»): PDF in -> PDF (CT/LV) out
Исходя из чего фраза
.
Поэтому, получив PDF с массированно применяемыми прозрачностями, Вы всегда по-сути сталкиваетесь с дилеммой:
1. Обрабатывать и трепить его APPE (зная об особенностях треппинга этим интерпретатором), но получить максимально возможно корректную интерпретацию прозрачностей;
2. Обрабатывать и трепить его CPSI (зная об особенностях треппинга этим интерпретатором), но очень внимательно отследить как отрабатывается flattening (опять же зная все нюансы этой операции - а их немало), и возможность НЕ получить корректную интерпретацию макета;
3. Потрепить его чем-либо "внешним" (методом добавления новых векторных объектов, которые собственно и будут представлять из себя "треппинг"), после чего передать его APPE (решение "непоточное").
Во всех рассматриваемых случаях при реализации треппинга применяются различные механизмы, имеющие различное происхождение проблем (типов взаимодействующих объектов) и их решений. И сравнивать их IMHO все равно, что решать кто победит в сражении – слон или кит? (Поправьте плиз, если это не так.)
Как я уже говорил, IMHO, было-бы более интересным сравнить каждый из приведенных механизмов в различных реализациях (мы говорим о "поточном треппинге"). И наиболее стоящие дискуссии механизмы это PDF->"physical" trapping->PDF и PDF->APPE trapping->bitmap.
Приаттачил предложенный Вами тест обработанный "поточно" следующим образом (настройки треппинга взяты из приведенного ув. Sabos последнего примера post#48): flattening->CPSI(InRIP trap) и APPE(InRIP trap). JPEG сделаны из "склеенного" растра.
Кстати, sliding trap достаточно хорошо виден.
Хотя и считаю обработку CPSI InRIP trapping - не показательной и "несовременной" (см. мой post#45).
Уважаемый niki81!niki81 сказал(а):
На мой взгляд вы пытаетесь сравнить несколько несравнимые вещи:
CPSI (PostScript Interpreter): PS in -> bitmap out
APPE (PDF Interpreter): PDF in -> bitmap out
PDF Toolbox (и прочие «псевдо-рипы»): PDF in -> PDF (CT/LV) out
Исходя из чего фраза
Не имеет права на жизнь, ибо (читай выше) в PostScript language в принципе нет такого понятия как transparency (см. PS language referenceniki81 сказал(а):
.Поэтому, получив PDF с массированно применяемыми прозрачностями, Вы всегда по-сути сталкиваетесь с дилеммой:
1. Обрабатывать и трепить его APPE (зная об особенностях треппинга этим интерпретатором), но получить максимально возможно корректную интерпретацию прозрачностей;
2. Обрабатывать и трепить его CPSI (зная об особенностях треппинга этим интерпретатором), но очень внимательно отследить как отрабатывается flattening (опять же зная все нюансы этой операции - а их немало), и возможность НЕ получить корректную интерпретацию макета;
3. Потрепить его чем-либо "внешним" (методом добавления новых векторных объектов, которые собственно и будут представлять из себя "треппинг"), после чего передать его APPE (решение "непоточное").
Во всех рассматриваемых случаях при реализации треппинга применяются различные механизмы, имеющие различное происхождение проблем (типов взаимодействующих объектов) и их решений. И сравнивать их IMHO все равно, что решать кто победит в сражении – слон или кит? (Поправьте плиз, если это не так.)
Как я уже говорил, IMHO, было-бы более интересным сравнить каждый из приведенных механизмов в различных реализациях (мы говорим о "поточном треппинге"). И наиболее стоящие дискуссии механизмы это PDF->"physical" trapping->PDF и PDF->APPE trapping->bitmap.
Приаттачил предложенный Вами тест обработанный "поточно" следующим образом (настройки треппинга взяты из приведенного ув. Sabos последнего примера post#48): flattening->CPSI(InRIP trap) и APPE(InRIP trap). JPEG сделаны из "склеенного" растра.
Кстати, sliding trap достаточно хорошо виден.
Хотя и считаю обработку CPSI InRIP trapping - не показательной и "несовременной" (см. мой post#45).
Вложения
- Сообщения
- 87
- Реакции
- 0
Ответ: Треппинг ин-рип и просто так
Bravo, вот какие дела:
Да, естественно механизм разный, но операция одна - треппинг, поэтому и сравниваю. Получаю между прочим разные результаты, в чём и цимес )
Тут разрешите с Вами не согласиться потому что интересует меня не механизм а результат. Обрабатывает ли CPSI прозрачности? Да, по-своему, он их плющит.
PDF с массированно применяемыми прозрачностями, это моя реально каждодневная к сожалению дилемма, описана вами без прикрас. К ней и был мой тест.
видал неправильно обработанной CPSI прозрачности. Флэттишь в верстке - да, тонкие белые линии, жирный текст и проч. Передаешь на рип - все значительно лучше.
Я бы очень хотел услышать мнение по поводу качества флэттенинга в CPSI на мете, полагаю что на сегодня это самый вылизанный движок.
2 Sabos: виноват, у Вас там тоже sliding trap на нижних парах с градиентом.
Bravo, вот какие дела:
Да, естественно механизм разный, но операция одна - треппинг, поэтому и сравниваю. Получаю между прочим разные результаты, в чём и цимес )
фраза APPE по сравнению с CPSI неправильно обрабатывает прозрачности
Не имеет права на жизнь, ибо (читай выше) в PostScript language в принципе нет такого понятия как transparency (см. PS language reference
Тут разрешите с Вами не согласиться потому что интересует меня не механизм а результат. Обрабатывает ли CPSI прозрачности? Да, по-своему, он их плющит.
PDF с массированно применяемыми прозрачностями, это моя реально каждодневная к сожалению дилемма, описана вами без прикрас. К ней и был мой тест.
Вроде концептуально все хорошо и правильно и так и хочется сделать, но присмотревшись к моему тесту, можно заметить, что АРРЕ не только пропустил треппинг на прозрачных обьектах, но и допустил цветовой сдвиг при их обработке (нижняя пара колец). Стало быть в нынешней реализации (по крайней мере в мете 7) APPE еще очень сыр и не может быть рекомендован к практике.
В моем тесте как ни странно самый лучший результат, прозрачные обьекты сплющены и потраплены идеально, цветовых сдвигов нет. И я вообще за два года на мете не
видал неправильно обработанной CPSI прозрачности. Флэттишь в верстке - да, тонкие белые линии, жирный текст и проч. Передаешь на рип - все значительно лучше.
Я бы очень хотел услышать мнение по поводу качества флэттенинга в CPSI на мете, полагаю что на сегодня это самый вылизанный движок.
Почему же, вполне поточное, покупаешь принтреди и вперед, массово трепить внутри пдф. И очень хорошо что треппинг можно потом и снять и подправить и (вот мне подсказывают на другом форуме) порядок наложения цветов просто меняется, а не через задания рипу и отсмотр preview. Останавливает только крайне низкое качество такого треппинга, особенно в исполнении Prinect. Вот тут был результат треппинга такой штукой от крео, так он мне больше понравился.
2 Sabos: виноват, у Вас там тоже sliding trap на нижних парах с градиентом.
- Статус