Помогите кто знает как в Иллюстратор вставить многоканальный растровый объект, чтобы потом весь макет корректно выводился например из Кварка или Индизайна??? У меня проблема такая: на привью в Индизайне все видно, а в посткрипте на месте растрового элемента видно то что под ним как будто его вообще нет.
> "DCS 2 в Иллюстраторе" - затея бесполезная
Это если после AI в цепочке ещё что-то будет.
Выводить же из самого AI — никаких препятствий.
Но много ли из самого AI выводится? Я уж и забыл, когда последний раз это делал.
Так что толкай DCS в InD и выводи с делением.
Если же тебе композит выводить надо, то крась растры в пантоны в самом AI или InD. Способы на форуме описаны.
Это если после AI в цепочке ещё что-то будет.
Выводить же из самого AI — никаких препятствий.
Но много ли из самого AI выводится? Я уж и забыл, когда последний раз это делал.
Так что толкай DCS в InD и выводи с делением.
Если же тебе композит выводить надо, то крась растры в пантоны в самом AI или InD. Способы на форуме описаны.
Shlyapa wrote:
>
> > "DCS 2 в Иллюстраторе" - затея бесполезная
>
> Это если после AI в цепочке ещё что-то будет.
> Выводить же из самого AI — никаких препятствий.
из вопроса Bmax123 следовало, что "в цепочке еще что-то будет". цитирую:
Помогите кто знает как в Иллюстратор вставить многоканальный растровый объект, чтобы потом весь макет корректно выводился например из Кварка или Индизайна???
конец цитаты.
> Но много ли из самого AI выводится? Я уж и забыл, когда
> последний раз это делал.
я еще не забыл. в основном приходилось выводить упаковку, причем нередко с огромными линкованными EPS'ами и DCS'ами. и хотя многие при фразе "вывод из AI" морщат нос, у меня по результату нареканий не возникало никогда.
>
> > "DCS 2 в Иллюстраторе" - затея бесполезная
>
> Это если после AI в цепочке ещё что-то будет.
> Выводить же из самого AI — никаких препятствий.
из вопроса Bmax123 следовало, что "в цепочке еще что-то будет". цитирую:
Помогите кто знает как в Иллюстратор вставить многоканальный растровый объект, чтобы потом весь макет корректно выводился например из Кварка или Индизайна???
конец цитаты.
> Но много ли из самого AI выводится? Я уж и забыл, когда
> последний раз это делал.
я еще не забыл. в основном приходилось выводить упаковку, причем нередко с огромными линкованными EPS'ами и DCS'ами. и хотя многие при фразе "вывод из AI" морщат нос, у меня по результату нареканий не возникало никогда.
> основном приходилось выводить упаковку
Сейчас все работы у меня многостраничные, потому AI работает только для записи EPS-ов для помещения в InD.
А ещё, всё чаще, в AI вектора только отрисовываются, а потом в InD вставляются как его собственная графика. (Это когда вектора не сложные, вроде логотипов не навороченных.)
Растры в пантоны крашу прямо в InD. Естественно, чтобы было что красить, делаю в PhS-е всё то же самое, как для записи DCS с CMYK+Pantone, но сохраняю CMYK в PSD или TIFF (чаще — в PSD), а Panton-ные каналы — в Grayscale TIFF-ы.
Ну а дуплексы (Duatone-s) из PhS в сохраняются в EPS (не DCS) и линкуются в InD.
И выводится всё хоть в композит, хоть с делением — как угодно.
Сейчас все работы у меня многостраничные, потому AI работает только для записи EPS-ов для помещения в InD.
А ещё, всё чаще, в AI вектора только отрисовываются, а потом в InD вставляются как его собственная графика. (Это когда вектора не сложные, вроде логотипов не навороченных.)
Растры в пантоны крашу прямо в InD. Естественно, чтобы было что красить, делаю в PhS-е всё то же самое, как для записи DCS с CMYK+Pantone, но сохраняю CMYK в PSD или TIFF (чаще — в PSD), а Panton-ные каналы — в Grayscale TIFF-ы.
Ну а дуплексы (Duatone-s) из PhS в сохраняются в EPS (не DCS) и линкуются в InD.
И выводится всё хоть в композит, хоть с делением — как угодно.
Shlyapa wrote:
>
> Растры в пантоны крашу прямо в InD. Естественно, чтобы было
> что красить, делаю в PhS-е всё то же самое, как для записи
> DCS с CMYK+Pantone, но сохраняю CMYK в PSD или TIFF (чаще — в
> PSD), а Panton-ные каналы — в Grayscale TIFF-ы.
<...skipped...>
> И выводится всё хоть в композит, хоть с делением — как угодно.
мне вот что любопытно. конечно, красить грейскейлы в верстке - прием известный. но вдруг подумал: насколько результат этих действий отличается от вывода собственно DCS? ведь формальное отличие есть. то есть, выражусь иначе: вполне ли корректна такая форма "цветоделения" с точки зрения PostScript? какие есть мнения?
>
> Растры в пантоны крашу прямо в InD. Естественно, чтобы было
> что красить, делаю в PhS-е всё то же самое, как для записи
> DCS с CMYK+Pantone, но сохраняю CMYK в PSD или TIFF (чаще — в
> PSD), а Panton-ные каналы — в Grayscale TIFF-ы.
<...skipped...>
> И выводится всё хоть в композит, хоть с делением — как угодно.
мне вот что любопытно. конечно, красить грейскейлы в верстке - прием известный. но вдруг подумал: насколько результат этих действий отличается от вывода собственно DCS? ведь формальное отличие есть. то есть, выражусь иначе: вполне ли корректна такая форма "цветоделения" с точки зрения PostScript? какие есть мнения?
> вполне ли корректна такая форма "цветоделения" с точки зрения PostScript? какие есть мнения?
А чего тут может быть некорректного?
CMYK-файл — это, по существу, уже делённый файл, в котором имеется 4 Grayscale-канала с указанием, какой краской каждый выводить. Дополнительные каналы (spot-ы) — те же самые grayscale-картинки, только другими красками помеченные.
В верстаке (в InD) ведь как растр красится? Указываешь, что, мол, эту grayscale-картинку выводить не в Black-канал (форму, краску), а в какой-то другой (другие, если не в Spot, а в Process покрасить). И даёшь overprint, если надо (при покраске дополнительных каналов для CMYK-картинки — надо). Overprint — вещь сугубо PostScript-овская, какие могут быть возражения.
Так шта-а…
> ведь формальное отличие есть
Какое?
--------------------------------------------
DCS, кстати, кварковская заморочка, насколько мне известно.
Точно не знаю, насколько она, эта заморочка, является стандартом, но в связи с чуждостью происхождения, адобовскому софту можно извинить некоторые сложности при работе с DCS-ами. Нет?
А чего тут может быть некорректного?
CMYK-файл — это, по существу, уже делённый файл, в котором имеется 4 Grayscale-канала с указанием, какой краской каждый выводить. Дополнительные каналы (spot-ы) — те же самые grayscale-картинки, только другими красками помеченные.
В верстаке (в InD) ведь как растр красится? Указываешь, что, мол, эту grayscale-картинку выводить не в Black-канал (форму, краску), а в какой-то другой (другие, если не в Spot, а в Process покрасить). И даёшь overprint, если надо (при покраске дополнительных каналов для CMYK-картинки — надо). Overprint — вещь сугубо PostScript-овская, какие могут быть возражения.
Так шта-а…
> ведь формальное отличие есть
Какое?
--------------------------------------------
DCS, кстати, кварковская заморочка, насколько мне известно.
Точно не знаю, насколько она, эта заморочка, является стандартом, но в связи с чуждостью происхождения, адобовскому софту можно извинить некоторые сложности при работе с DCS-ами. Нет?
> но вдруг подумал: насколько результат этих действий отличается от вывода собственно DCS? ведь формальное отличие есть
arhip, как можно сравнивать стандартный формат файла и дополнительное удобство, предоставляемое программой верстки? это разве "формальное отличие"?
> вполне ли корректна такая форма "цветоделения" с точки зрения PostScript?
так ведь, дело то в том, что "с точки зрения PostScript" нет никаких крашенных грейскейлов. Host (программа верстки) полностью отвечае за то, чтобы окрасить тифф и представить его в постскрипт (пдф) в том или ином подходящем для постскрипта виде. В зависимости от того, будет ли вывод композитный или сепаренный, каждая программа (ну, кварк и ИД, будем рассматривать, а фрихэнд пусть отдохнет) реализует это "окрашивание грейскейла", в том числе окрашивание фона (fake duotone), в той или иной степени корректно.
Например, известный (не сомневаюсь) тебе, arhip, глюк кварка, когда черный грейскейл помещается в цветной бокс. Оверпринт черного в этом случае реализуется только при сепаренном выводе. В композите мы получим ЦМИК-имидж, в котором оверпринт благополучно похерен.
ИД, правда, радует еще больше. Черный тиф, помещенный в цветной бокс, даже если ручками назначить оверпринт имиджу, даже при сепаренном выводе вышибает под собой дырку в фоне. Ха, но если поместить черный тифф на _другой_ цветной бокс, то оверпринт выполняется. Но, сдается мне, не в этом заключается удобство "fake duotone", чтобы для одного имиджа рисовать 2 бокса. (А может, это фича ИД? что оверпринт имиджа не работает для собственного бокса? Ну, не настолько я знаю ИД)
Впрочем, не такой частый случай, черный на фоне. В остальном обе программы с окрашиванием тифов работают успешно. Для кварка нужны, правда, доп. экстеншны, чтобы красить тифы (и фоны) в пантоны и выводить композитом. Что там с ИД, на 100%, опять же, не знаю. Может все и так работает
---
ну а DCS?
Desktop Color Separation (DCS) is an enhancement to the Encapsulated PostScript (EPS) graphic file format
(заглавная фраза с http://www.adobe.com/support/techdocs/c2c2.htm)
_enhancement_, mind you. Перевод не требуется?
Эта "чуждая" "заморочка" будет еще долго приветствоваться в т.ч. и самой адоби, пока она не введет в своих (а там и другим будет смысл заморачиваться) продуктах полноценную поддержку таких цветовых систем, как DeviceN и Separation. (Введенных в постскрипт ажно в 1999 году)
(че-то я устал от писанины) недавно рядом говорили о DCS в композитном workflow. См. где-то рядом.
Формат форматом, но и здесь нам интересно, прежде всего, как тот или иной host (DCS-consumer, в данном случае программа верстки) работает с этим форматом
в двух словах, этот формат (стандарт 1993 года (версия 2 в 1995 году)), конечно, изначально ориентирован на сепаренный workflow
arhip, как можно сравнивать стандартный формат файла и дополнительное удобство, предоставляемое программой верстки? это разве "формальное отличие"?
> вполне ли корректна такая форма "цветоделения" с точки зрения PostScript?
так ведь, дело то в том, что "с точки зрения PostScript" нет никаких крашенных грейскейлов. Host (программа верстки) полностью отвечае за то, чтобы окрасить тифф и представить его в постскрипт (пдф) в том или ином подходящем для постскрипта виде. В зависимости от того, будет ли вывод композитный или сепаренный, каждая программа (ну, кварк и ИД, будем рассматривать, а фрихэнд пусть отдохнет) реализует это "окрашивание грейскейла", в том числе окрашивание фона (fake duotone), в той или иной степени корректно.
Например, известный (не сомневаюсь) тебе, arhip, глюк кварка, когда черный грейскейл помещается в цветной бокс. Оверпринт черного в этом случае реализуется только при сепаренном выводе. В композите мы получим ЦМИК-имидж, в котором оверпринт благополучно похерен.
ИД, правда, радует еще больше. Черный тиф, помещенный в цветной бокс, даже если ручками назначить оверпринт имиджу, даже при сепаренном выводе вышибает под собой дырку в фоне. Ха, но если поместить черный тифф на _другой_ цветной бокс, то оверпринт выполняется. Но, сдается мне, не в этом заключается удобство "fake duotone", чтобы для одного имиджа рисовать 2 бокса. (А может, это фича ИД? что оверпринт имиджа не работает для собственного бокса? Ну, не настолько я знаю ИД)
Впрочем, не такой частый случай, черный на фоне. В остальном обе программы с окрашиванием тифов работают успешно. Для кварка нужны, правда, доп. экстеншны, чтобы красить тифы (и фоны) в пантоны и выводить композитом. Что там с ИД, на 100%, опять же, не знаю. Может все и так работает
---
ну а DCS?
Desktop Color Separation (DCS) is an enhancement to the Encapsulated PostScript (EPS) graphic file format
(заглавная фраза с http://www.adobe.com/support/techdocs/c2c2.htm)
_enhancement_, mind you. Перевод не требуется?
Эта "чуждая" "заморочка" будет еще долго приветствоваться в т.ч. и самой адоби, пока она не введет в своих (а там и другим будет смысл заморачиваться) продуктах полноценную поддержку таких цветовых систем, как DeviceN и Separation. (Введенных в постскрипт ажно в 1999 году)
(че-то я устал от писанины) недавно рядом говорили о DCS в композитном workflow. См. где-то рядом.
Формат форматом, но и здесь нам интересно, прежде всего, как тот или иной host (DCS-consumer, в данном случае программа верстки) работает с этим форматом
в двух словах, этот формат (стандарт 1993 года (версия 2 в 1995 году)), конечно, изначально ориентирован на сепаренный workflow
Вадим wrote:
>
> > но вдруг подумал: насколько результат этих действий
> отличается от вывода собственно DCS? ведь формальное отличие
> есть
>
> arhip, как можно сравнивать стандартный формат файла и
> дополнительное удобство, предоставляемое программой верстки?
> это разве "формальное отличие"?
соглашусь. настолько "отличие", что уже более "фактическое", нежели "формальное".
ясно, что источник растрового изображения в таком случае - разный (в одном случае - часть (канал) EPS DCS, в другом GS-изображение с назначенным ему цветом). однако, меня интересовало, насколько эта разница видна в теле PS-файла. Или, "переварившись" в PS, оба варианта уже мало отличимы друг от друга?
сам я этого не знаю, но твой следующий текст мне кажется вполне убедительным. я его процитирую целиком:
> дело то в том, что "с точки зрения PostScript" нет
> никаких крашенных грейскейлов. Host (программа верстки)
> полностью отвечае за то, чтобы окрасить тифф и представить
> его в постскрипт (пдф) в том или ином подходящем для
> постскрипта виде. В зависимости от того, будет ли вывод
> композитный или сепаренный, каждая программа (ну, кварк и ИД,
> будем рассматривать, а фрихэнд пусть отдохнет) реализует это
> "окрашивание грейскейла", в том числе окрашивание фона (fake
> duotone), в той или иной степени корректно.
***конец цитаты
из чего остается сделать вывод: вывод DCS - это вывод особого цветоделенного формата (кот. является "расширением" фирмы Quark к формату EPS), а вывод "окрашенного GS" - это цветоделение с помощью функций программы верстки или программы создания иллюстраций. может, я не очень точен, но развивать не буду. sapienti sat.
описанные тобой далее примеры корректности / некорректности программ опускаю. а также все о DCS.
спасибо за ответ
>
> > но вдруг подумал: насколько результат этих действий
> отличается от вывода собственно DCS? ведь формальное отличие
> есть
>
> arhip, как можно сравнивать стандартный формат файла и
> дополнительное удобство, предоставляемое программой верстки?
> это разве "формальное отличие"?
соглашусь. настолько "отличие", что уже более "фактическое", нежели "формальное".
ясно, что источник растрового изображения в таком случае - разный (в одном случае - часть (канал) EPS DCS, в другом GS-изображение с назначенным ему цветом). однако, меня интересовало, насколько эта разница видна в теле PS-файла. Или, "переварившись" в PS, оба варианта уже мало отличимы друг от друга?
сам я этого не знаю, но твой следующий текст мне кажется вполне убедительным. я его процитирую целиком:
> дело то в том, что "с точки зрения PostScript" нет
> никаких крашенных грейскейлов. Host (программа верстки)
> полностью отвечае за то, чтобы окрасить тифф и представить
> его в постскрипт (пдф) в том или ином подходящем для
> постскрипта виде. В зависимости от того, будет ли вывод
> композитный или сепаренный, каждая программа (ну, кварк и ИД,
> будем рассматривать, а фрихэнд пусть отдохнет) реализует это
> "окрашивание грейскейла", в том числе окрашивание фона (fake
> duotone), в той или иной степени корректно.
***конец цитаты
из чего остается сделать вывод: вывод DCS - это вывод особого цветоделенного формата (кот. является "расширением" фирмы Quark к формату EPS), а вывод "окрашенного GS" - это цветоделение с помощью функций программы верстки или программы создания иллюстраций. может, я не очень точен, но развивать не буду. sapienti sat.
описанные тобой далее примеры корректности / некорректности программ опускаю. а также все о DCS.
спасибо за ответ
> однако, меня интересовало, насколько эта разница видна в теле PS-файла. Или, "переварившись" в PS, оба варианта уже мало отличимы друг от друга?
да, но
епс включается в пс целиком, со всеми потрохами. DCS -- это епс, ссылающийся на другие епс (т.к. каждый канал dcs -- это файл епс, грейскельный). При цветоделении host (dcs-consumer) пишет в каждую плату соотв. канал dcs (в виде того самого епс файла (канала), от 1-го до последного байта, буквально)
при делении публикации с крашенным тифом -- в теле ps у нас только greyscale image, в виде соотв. ps оператора.
"почти" то же самое. Т.к. есть варианты сохранения dcs с halftones & transfer functions. Надо еще смотреть как поведет себя например recombine на рипе или тот же seps2comp, например. И т.д. Вроде бы, и для 99% работ, то же самое. А если покопать, что еще может обнаружиться?
(интереснее случай с композитным пс, но я так понимаю, это выходит за рамки конкретной темы)
да, но
епс включается в пс целиком, со всеми потрохами. DCS -- это епс, ссылающийся на другие епс (т.к. каждый канал dcs -- это файл епс, грейскельный). При цветоделении host (dcs-consumer) пишет в каждую плату соотв. канал dcs (в виде того самого епс файла (канала), от 1-го до последного байта, буквально)
при делении публикации с крашенным тифом -- в теле ps у нас только greyscale image, в виде соотв. ps оператора.
"почти" то же самое. Т.к. есть варианты сохранения dcs с halftones & transfer functions. Надо еще смотреть как поведет себя например recombine на рипе или тот же seps2comp, например. И т.д. Вроде бы, и для 99% работ, то же самое. А если покопать, что еще может обнаружиться?
(интереснее случай с композитным пс, но я так понимаю, это выходит за рамки конкретной темы)
Bmax123 wrote:
>
> Да тут макет такой что нельзя картинку просто поверх всего
> положить ее в некоторых местах векторные элементы закрывают,
> так что все в Иллюстраторе нужно делать!
если векторы просто перекрываются с картинкой - то нет никаких проблем, Шляпа прав. Даже если часть векторов лежит под картинкой, а другая - над ней, надо просто разбить вектор на 2 файла и заверстывать их в нужном порядке относительно растра. это самое обычное и часто встречающееся решение.
а вот если вектора требуют очень точного *совмещения* с растром, например так, чтобы линия в 0,5 pt легла точно на какую-то часть растровой картинки - это уже другая история. и требует другого подхода.
но и здесь можно выкрутится. я, например, для этого временно вставлял векторные элементы, требующие совмещения, в фотошоп - причем так, чтобы и в векторе, и в растре присутствовала одна и та же габаритная рамка, совмещал все в шопе, как мне надо, грохал лишние пути (или оставлял - по настроению) - но оставлял эту габаритную рамку, из которой делал clipping path - и все чудесно совмещалось в верстке! что касается кварка - то лучше совмещать в 5-ке, он корректно обрабатывает конверсию измерений pt <-> mm, и смещения EPS в боксе не происходит. в ИнДи, думаю, тоже этой проблемы нет.
>
> Да тут макет такой что нельзя картинку просто поверх всего
> положить ее в некоторых местах векторные элементы закрывают,
> так что все в Иллюстраторе нужно делать!
если векторы просто перекрываются с картинкой - то нет никаких проблем, Шляпа прав. Даже если часть векторов лежит под картинкой, а другая - над ней, надо просто разбить вектор на 2 файла и заверстывать их в нужном порядке относительно растра. это самое обычное и часто встречающееся решение.
а вот если вектора требуют очень точного *совмещения* с растром, например так, чтобы линия в 0,5 pt легла точно на какую-то часть растровой картинки - это уже другая история. и требует другого подхода.
но и здесь можно выкрутится. я, например, для этого временно вставлял векторные элементы, требующие совмещения, в фотошоп - причем так, чтобы и в векторе, и в растре присутствовала одна и та же габаритная рамка, совмещал все в шопе, как мне надо, грохал лишние пути (или оставлял - по настроению) - но оставлял эту габаритную рамку, из которой делал clipping path - и все чудесно совмещалось в верстке! что касается кварка - то лучше совмещать в 5-ке, он корректно обрабатывает конверсию измерений pt <-> mm, и смещения EPS в боксе не происходит. в ИнДи, думаю, тоже этой проблемы нет.