InDesign V&S (против) QuarkXPress

  • Автор темы Автор темы alonia
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.
Ответ: InDesign V&S (против) QuarkXPress

ch_alex: не в обиду, но Вы подходите к вопросу однобоко. В журнальном, к примеру, препрессе, вещи и похлеще, чем "Подлинкуйте картинку 10х10 см х 100 ppi, затем перебейте ее размер в Шопе на 20х20 см х 50 ppi" бывают.
 
Ответ: InDesign V&S (против) QuarkXPress

Flame сказал(а):
В журнальном, к примеру, препрессе, вещи и похлеще, чем "Подлинкуйте картинку 10х10 см х 100 ppi, затем перебейте ее размер в Шопе на 20х20 см х 50 ppi" бывают.
Бывают. Но это компьютерные журналы, ничего не имеющие общего с топ-журналами.
В первых мыло, во вторых - лепота, на которую хочется смотреть.
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Извините, но вы занимаетесь фигнёй.
Не следует перебивать размеры в миллиметрах - вы должны ориентироваться на те размеры, что есть в полосе. Не умеете правильно работать - учитесь.

:) Это всего лишь пример. На что и как я ориентируюсь - ниже.
 
Ответ: InDesign V&S (против) QuarkXPress

Координаты/размеры можно посчитать (хотя, имхо, это дурная работа) в том случае, если есть исходные Low Res файлы. А если их нет? А есть только линки на них. Из этих линков нужную информацию для пересчета не вытянешь..
Это?

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

Нет, если есть острая производственная необходимость клепать по-быстрому макулатуру - можно использовать hardcore-масштабирование в публикации. Но качественный, "звенящий" макет таким образом не сделать.
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Для того, чтобы поставить картинку точно в позицию, следует изменить только разрешение. Т.е. сделать копию фотки в тот же физический размер, но с нормальным разрешением под печать. Размеры изменять вредно. А раз уж изменили - работайте ручками, как на монтажном столе. Потому что Кварк - это идеология монтажного стола, где можно смонитровать текст и фото и быстренько подрезать последние.

Эт все ясно. А вот Вам пример из жизни: при верстке журнала верстальщик линкует Low Res`ы не заморачиваясь их физическими размерами и разрешением. Далее верстка попадает в мои руки БЕЗ Low Res`ов (есть только линки на них). Вместо Low Res в моем распоряжении имеются Hi Res`ы, размеры и разрешение которых НЕ ПРИВЕДЕНЫ к их размерам на полосе - это просто фотки из фотобанков. Территориально мы разнесены (журнал закачивается на мой фтп).
В результате - куча лишней работы, от которой хочется избавиться. В InDi было бы все проще, но это не главное. Главное - оптимизировать процесс.

ch_alex сказал(а):
ЗЫ. Масштабирование в публикации требуется только для финишной подгонки. Всё, что больше меньше 90...110% - лучше изначально подгонять в Шопе к нужным размерам и разрешению. Дело в том, что шарпинг в Шопе выполняется попиксельно, это одна из финишныхх операций перед установкой фотографий. Если сильно смасштабировать картинку, то изменится и ширна шарпинга, что приведёт либо к замыливанию картинки, либо эта зона расширится до того, что будет выглядеть некрасиво. Если шарпинг на финише не делать, то получается мыло. Но и слишком увлекаться этим не стоит. Кто не занимается постобработкой и прибиванием джипеговских квадратов - моё ЗЫ можете игнорировать.

Теперь о разрешении, масштабировании и шарпинге:
Во времена 4-го Кварка и вывода в PS действительно нужно было приводить все к 300 ppi вручную - на то было множество причин, да и автоматом это в принципе не делалось.
Сейчас, в эпоху PDF - все это дурная работа - все можно делать автоматом.

Как не попасть при этом на "мыло":

Во первых, необходимо использовать фотки с разрешением (для размера на полосе) не менее 250-300 ppi (зависит от линиатуры и способа растрирования, в некоторых случаях может потребоваться большее разрешение). В реальной жизни это не всегда получается, но тут уж ничего не поделаешь - либо "тянешь" фотку до нужного размера, предупреждая о последствиях, либо просишь ее поменять.

Если же фотки имеют запас по разрешению - то я их сначала обрабатываю (цветокоррекция, шарпинг, цветоделение), затем ставлю на полосу, не заморачиваясь подгонкой к заветным 300 ppi. Даже если фотка имеет 20-кратный запас по разрешению.
Про шарпинг: его контроль осуществляется визуально на мониторе, при этом масштаб отображения (в мм) устанавливаю примерно 200-300% от их размера на полосе. Зона шарпинга подбирается в ручную и может быть самой разной - для фоток с избыточным разрешением - больше, для маленьких фоток - меньше.

После того, как все подлинковано - пишем PDF. Вот тут важно правильно установить параметры "сброса" излишнего разрешения.
Есть рекомендации "если больше 301, то сбрасываем до 300" - это НЕПРАВИЛЬНО! (а в кварке именно так заложено)
Если мы обработаем таким образом картинку с разрешением, например 350 - то в результате получим "мыло".
По умолчанию в Акробате задано "если больше 450, то сбрасываем до 300" - это более грамотный вариант.
Поясню подробнее: фотки разрешением 300 - 450 остаются "как есть" (правда в этом случае немного сильнее грузится вывод, но они нынче мощные) и "мыло" не возникает. Фотка с большим запасом по разрешению (450 и выше) при сбросе разрешения практически не "мылится".

Надеюсь понятно изложил...

Добавлено: этот подход я практикую в основном для журналов и каталогов. Если "вылизывается" отдельная рекламная полоса - там конечно все делается "в конечный размер".
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Это?

Во-первых, информация имеется - размер окошка под изображение в вёрстке и информация в панели Measurements.

Если фотка отображена частично - то слишком сложная "математика" получается: нужно учитывать размер, масштаб и смешение.
Что, каждую фотку в Экселе обсчитывать?

Об остальном и "звенящих" макетах - см. выше
 
Ответ: InDesign V&S (против) QuarkXPress

Pilot Pirks сказал(а):
Сейчас, в эпоху PDF - все это дурная работа - все можно делать автоматом.
Пулемётом. :)
Почему-то с появлением стандарта появилось мнение (и даже убеждение), что "этот волшебный PDF/X-1a" всё сам сделает, нам же остаётся втиснуть всякое разноразмерное и непонятное барахло в публикацию и нажать Print.
Как не попасть при этом на "мыло":

Про шарпинг: его контроль осуществляется визуально на мониторе, при этом масштаб отображения (в мм) устанавливаю примерно 200-300% от их размера на полосе.
Ага, вручную выставлять масштаб просмотра для каждой картинки... А потом ещё и устанавливать на каждую радиус шарпенинга и размер зерна для шума вручную задавать, и opacity слоя... У меня экшен в Шопе написан, который колбасит нормированные по размеру и разрешению картинки. Из одной папки в другую. А я пью кофе. Только потому, что у меня в картинках заданы размеры в милиметрах и разрешение. Потом остаётся только подменить иллюстрации и окончательно пересмотреть полосы. Двигать приходилось крайне редко.

Есть рекомендации "если больше 301, то сбрасываем до 300" - это НЕПРАВИЛЬНО! (а в кварке именно так заложено)
Не наблюдал. В Кварке 4-ке, 5-ке и 6-ке выдаётся всё, что есть, с учётом масштаба. И никакого приведения к 300 ppi. О 7-ке не скажу - не пробовал.
Добавлено: этот подход я практикую в основном для журналов и каталогов. Если "вылизывается" отдельная рекламная полоса - там конечно все делается "в конечный размер".
Видимо, мы говорим о разных журналах. Предположим, можно сопоставить отраслевой журнал энергетической компании (каталог металлообрабатывающих станков, прокатных станов, электромоторов и пр. железа) и журнал EGO. EGO и иже с ним не простит никаких пробоев в качестве - там каждая фотография==рекламная полоса. Сплоховал - на тебе выходное пособие и ни в чём себе не отказывай. Кроме того, работа в любом нормальном журнале заранее планируется, определяется размер иллюстраций и объём текста (в знаках). Каждая группа имеет в своём списке несколько статей и конкертно за них отвечает.

Иначе это превращается в цирк. Да, можно получить на автомате нечто красивое, но далеко не всегда можно положиться на механизмы даунсемплинга после шарпинга в публикации. И проконтролировать это несколько сложнее, да и лишняя работа - а Шоп зачем до перегонки в ПДФ дёргали? Понятно, почему я ратую за полную подготовку в Шопе, а потом размещение фотки в публикации без масштабирования?
 
Ответ: InDesign V&S (против) QuarkXPress

Pilot Pirks сказал(а):
Пока в моей, в принципе стандартной, ситуации Кварк ведет себя не лучшим образом.
ок, я неправильно понял Ваш вопрос с предыдущей страницы. Да, если фототобанк предоставляет "превью" высотой 400 px и "финал" 3000 px, их физические размеры/разрешение никому неинтересны, верстальщик заверстывает "превью", и далее, при апдейте, ИД очень умно сам помещает "финал" как следует. Кварк сам по себе такого не сделает. Он предполагает другие подходы. Например, сканирование/фотографирование, затем каким-нибудь сэмплером делаются lowres'ы, отправляются верстальщику. Hires'ы подставляются либо простым апдейтом, либо через get picture + maintain attributes. Да Вы и сами это знаете. Повторю, что если ретушер/цветокорректор еще и откропил фотографию, то "умничание" индизайна только вредит. Жалобы на это, в форумах, имеются. Так что у каждого подхода свои минусы. По поводу того, может ли какой-либо XT модифицировать поведение кварка при апдейте линков, -- не знаю. За 15 лет должен был кто-то сделать XT или эппл-скрипт на эту тему, _если_ проблема действительно актуальна
 
Ответ: InDesign V&S (против) QuarkXPress

Pilot Pirks сказал(а):
Если фотка отображена частично - то слишком сложная "математика" получается: нужно учитывать размер, масштаб и смешение.
Что, каждую фотку в Экселе обсчитывать?
Я же говорил - Индезайн тут тоже не поможет - та же проблема с фактическим отличием превью и финиша. Но если финишная фотография сделана в размер и подрезана (т.е. не соответствует превью, но содержит только полезное изображение), то есть такой шоткат Ctrl+Shift+M - отцентровал и успокоился. Можно и Ctrl+Shift+F (вогнал по масштабу). Если не подрезали финишную фотку - неправильно, это ваша лень сработала. Хотя... если проблема только в разрешении, то можно и не подрезать - меньше мороки.

Поэтому в Шопе финишные фотки режем в размер на полосе, даунсемплим (если нужно) до технически обоснованных разрешений, сохраняем. На автомате делаем постобработку всех требующих этого иллюстраций. Открываем вёрстку, обновляем и проходим по полосам. Если превьюшки догадались ставить в 100%, то останется только отцентровать финишную картинку.
 
Ответ: InDesign V&S (против) QuarkXPress

1998 сказал(а):
ок, я неправильно понял Ваш вопрос с предыдущей страницы. Да, если фототобанк предоставляет "превью" высотой 400 px и "финал" 3000 px, их физические размеры/разрешение никому неинтересны, верстальщик заверстывает "превью", и далее, при апдейте, ИД очень умно сам помещает "финал" как следует. Кварк сам по себе такого не сделает. Он предполагает другие подходы. Например, сканирование/фотографирование, затем каким-нибудь сэмплером делаются lowres'ы, отправляются верстальщику. Hires'ы подставляются либо простым апдейтом, либо через get picture + maintain attributes. Да Вы и сами это знаете. Повторю, что если ретушер/цветокорректор еще и откропил фотографию, то "умничание" индизайна только вредит. Жалобы на это, в форумах, имеются. Так что у каждого подхода свои минусы. По поводу того, может ли какой-либо XT модифицировать поведение кварка при апдейте линков, -- не знаю. За 15 лет должен был кто-то сделать XT или эппл-скрипт на эту тему, _если_ проблема действительно актуальна
В моем случае Hi Res`ы никто не кропит...
В общем, все ясно. Решается только математическими расчетами и подгонкой в Шопе.
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Я же говорил - Индезайн тут тоже не поможет - та же проблема с фактическим отличием превью и финиша. Но если финишная фотография сделана в размер и подрезана (т.е. не соответствует превью, но содержит только полезное изображение), то есть такой шоткат Ctrl+Shift+M - отцентровал и успокоился. Можно и Ctrl+Shift+F (вогнал по масштабу). Если не подрезали финишную фотку - неправильно, это ваша лень сработала. Хотя... если проблема только в разрешении, то можно и не подрезать - меньше мороки.

Ну, про шоткаты мне не надо рассказывать... :)
В моем случае финишные фотографии никто не кропит (зачем это вообще делать?), поэтому в ИнДи все на ура проходит.
А с Кварком - видимо кроме математических расчетов и приведения к нужному размеру в шопе вариантов нет.
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Пулемётом. :)
Почему-то с появлением стандарта появилось мнение (и даже убеждение), что "этот волшебный PDF/X-1a" всё сам сделает, нам же остаётся втиснуть всякое разноразмерное и непонятное барахло в публикацию и нажать Print.
А причем тут PDF/X-1a? Кстати, я никогда не использую на выходе этот стандарт.
ch_alex сказал(а):
Пулемётом. :)
Ага, вручную выставлять масштаб просмотра для каждой картинки... А потом ещё и устанавливать на каждую радиус шарпенинга и размер зерна для шума вручную задавать, и opacity слоя... У меня экшен в Шопе написан, который колбасит нормированные по размеру и разрешению картинки. Из одной папки в другую. А я пью кофе. Только потому, что у меня в картинках заданы размеры в милиметрах и разрешение. Потом остаётся только подменить иллюстрации и окончательно пересмотреть полосы. Двигать приходилось крайне редко.
Шарпинг пачками и не глядя... Хороший способ получить "звенящие" фотографии. :)
ВСЕ исходники разные. И КАЖДЫЙ из них требует ИНДИВИДУАЛЬНОГО подхода. Разные объективы, сканеры, фотоаппараты. Различная степень предварительной обработки (а фотографии в фотобанках обязательно подвергаются таковой). Если их все под одну гребенку - то ничего хорошего из этого не выйдет, проверено.
А экшены в фотошопе и я широко использую. Например для шарпинга есть свой экшен, который выдает 10 слоев-вариантов с разными параметрами. Остается только пощелкать и выбрать оптимальный или скомбинировать парочку по принципу "глаза из второго а волосы из четвертого слоя"
Кроме того, шарпинг это не единственная и даже не самая основная операция, которая необходима для получения "звенящей" фотографии. А эти операции на автомате вообще нельзя делать - только глаза и руки...
Так что кофе пить - после сдачи номера :)
ch_alex сказал(а):
Не наблюдал. В Кварке 4-ке, 5-ке и 6-ке выдаётся всё, что есть, с учётом масштаба. И никакого приведения к 300 ppi. О 7-ке не скажу - не пробовал.
Речь идет о семерке. Там это есть в параметрах экспорта в PDF.
Кроме того, там есть возможность автоматом привести все подлинкованые картинки к нужному разрешению и откропить их. Но тупо по алгоритму "301 в 300", поэтому не пользуюсь.
Кстати, для ИнДи существует широкоизвестный плагин, который позволяет тоже самое, только еще и с шарпингом.
ch_alex сказал(а):
Видимо, мы говорим о разных журналах. Предположим, можно сопоставить отраслевой журнал энергетической компании (каталог металлообрабатывающих станков, прокатных станов, электромоторов и пр. железа) и журнал EGO. EGO и иже с ним не простит никаких пробоев в качестве - там каждая фотография==рекламная полоса. Сплоховал - на тебе выходное пособие и ни в чём себе не отказывай. Кроме того, работа в любом нормальном журнале заранее планируется, определяется размер иллюстраций и объём текста (в знаках). Каждая группа имеет в своём списке несколько статей и конкертно за них отвечает.

Иначе это превращается в цирк. Да, можно получить на автомате нечто красивое, но далеко не всегда можно положиться на механизмы даунсемплинга после шарпинга в публикации. И проконтролировать это несколько сложнее, да и лишняя работа - а Шоп зачем до перегонки в ПДФ дёргали? Понятно, почему я ратую за полную подготовку в Шопе, а потом размещение фотки в публикации без масштабирования?

А я ратую за исключения из воркфлоу ненужной работы. Посчитайте сколько времени нужно затратить на подгонку в нужные размеры всех фотографий для журнала 128 полос? А если их при этом еще и кропить?
Лучше истратить это время на что-то более полезное...
А что касается качества - проделайте на досуге эксперимент:
Обработайте фотку с исходным разрешением больше 450 до "звенящего" качества, затем сбросьте разрешение до 300.
А теперь эту же фотку приведите сначала к разрешению 300, а потом обработайте.
Сравните результаты. Разницу разве что под микроскопом можно будет разглядеть... И не факт, что второй вариант будет лучше.
 
Ответ: InDesign V&S (против) QuarkXPress

Pilot Pirks сказал(а):
Посчитайте сколько времени нужно затратить на подгонку в нужные размеры всех фотографий для журнала 128 полос?

Подсказываю: Бесплатный скрипт Crop&Resize для индюка приведет пару сотен картинок к нужному размеру, разрешению и цветовой модели за 5-10 минут. Плюс по желанию можно автоматический шарпенинг сделать. Всячески рекомендую. Лежит тут: http://toolbox.rudtp.ru/index.php?id=202.

p.s. Для кварка тоже похожая штука есть - Badias Vista, но у меня она нормально не работала да и возможностей у нее меньше.
 
Ответ: InDesign V&S (против) QuarkXPress

-IKS- сказал(а):
Подсказываю: Бесплатный скрипт Crop&Resize для индюка приведет пару сотен картинок к нужному размеру, разрешению и цветовой модели за 5-10 минут. Плюс по желанию можно автоматический шарпенинг сделать. Всячески рекомендую. Лежит тут: http://toolbox.rudtp.ru/index.php?id=202.

p.s. Для кварка тоже похожая штука есть - Badias Vista, но у меня она нормально не работала да и возможностей у нее меньше.
Спасибо, я выше про него писал: "...Кстати, для ИнДи существует широкоизвестный плагин, который позволяет тоже самое, только еще и с шарпингом"
В Кварке (7) Vista встроена, также см. выше...
 
Ответ: InDesign V&S (против) QuarkXPress


Не по теме:
Мужики, хорош уже! Давайте теперь про другие "10 отличий".
 
Ответ: InDesign V&S (против) QuarkXPress

Pilot Pirks сказал(а):
А причем тут PDF/X-1a? Кстати, я никогда не использую на выходе этот стандарт.
Какие отступления вы сделали от PDF/X? Мы тоже за основу взяли PDF/X-1a, но ввели ещё более жёсткие ограничения по шрифтам и профилям. Мы плёнки выводим, поэтому нам профили не нужны.

Шарпинг пачками и не глядя... Хороший способ получить "звенящие" фотографии. :)
Я чётко написал: "На автомате делаем постобработку всех требующих этого иллюстраций". Я их сортирую, понимаете? А потом на каждую группу натравливаю свои заморочки - плющу слои/конвертирую в CMYK/шарплю и так далее. Причём сортировка идёт в зависимости от цветности, слойности и формата данных. Информацию можно прочитать прямым поиском в файлах. Это тоже можно автоматизировать, но я как-то ленюсь изучить Piton. ;)

Речь идет о семерке. Там это есть в параметрах экспорта в PDF.
Не люблю экспорт и не рекомендую никому им пользоваться. Есть печать, есть Дистиллер - вперёд. Дистиллером можно сделать хотфолдеры на все случаи жизни и бросать туда постскрипты (или ESP - кому как нравится). А там и постобработка в Питстоп-сервере. Причём на каждый канал отдельная. Что мне этот жалкий экспорт? Тем более, что экспорт публикации из Индеза создаёт намного больше проблем, нежели печать её же через PS-драйвер. Естественно речь идёт об относительно устаревших РИПах. Но тут важна совместимость, а не мнимое удобство экспорта. На самом деле можно сделать профили печати, которые будут перебивать всякие кривые внутренние установки. Это даёт гарантию, что вы сделаете PDF, который одинаково хорошо воспримется разными РИПами (которые PDF-ориентированы) и Препсами разных версий.

А я ратую за исключения из воркфлоу ненужной работы. Посчитайте сколько времени нужно затратить на подгонку в нужные размеры всех фотографий для журнала 128 полос? А если их при этом еще и кропить?
Что, не надо кропить? У вас избыток места на винте? Архивировать времени и дисков не жалко?
Вы ещё скажите, что сканируете все фотографии одним махом и потом сдвигаете общую сборку в окне так, чтобы была видна только одна фотография... Я встречал подобные работы, только в векторных вариантах. При неосторожной подмене (что в Кварке, что в Индезе), после съезда картинок, заказчик шёл переделать макет, ибо центровке такое "художество" не подлежит.

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

Вы не забывайте, что ваш битмап пройдёт преобразование в типографский растр, и по этой причине шарпинг должен иметь радиус, соотвествтующий линиатуре вывода/печати. Для газетки один радиус (сообразуется с финальным разрешением картинки), для меловки - другой.

ЗЫ. Мне тут коллега сдаёт на вывод цветопробы. И весьма часто. У него там масштабирование доходит до 20%, а постскрипты достигают размера 1,2 гигабайта на A3-Extra. Дистиллить запрещает, поэтому вывожу как есть. РИП не даунсемплит, но растрирует достаточно быстро. "Звенящего" макета не получается, разве что отрастрированные надписи получаются с чёткими краями.
 
Ответ: InDesign V&S (против) QuarkXPress

ch_alex сказал(а):
Не люблю экспорт и не рекомендую никому им пользоваться. Есть печать, есть Дистиллер - вперёд. Дистиллером можно сделать хотфолдеры на все случаи жизни и бросать туда постскрипты (или ESP - кому как нравится).

В семерке экспорт можно по хитрому настроить - через Дистиллер. См. соседнюю тему...
А по остальному - мне кажется, что наш диалог ушел в сторону от основной темы данной ветки: мы не "верстаки" обсуждаем а два отличающихся подхода к построению воркфлоу. Может как-то перенести дискуссию в ветку "пре-пресс"?
А то тут народ уже возмущается. :)
 
Ответ: InDesign V&S (против) QuarkXPress

@diz@ сказал(а):

Не по теме:
Мужики, хорош уже! Давайте теперь про другие "10 отличий".
А собственно сравнивать семерку с CS2 особого смысла не вижу - через пару месяцев CS3 будет.
И даже в сравнении с CS2 - полный разгром по всем фронтам...
Даже те опции, которые имеются в обоих верстаках, в InDi реализованы, как правило, удобнее.
Основная ниша для нового Кварка - это те организации, в которых рабочий процесс построен на предыдущих версиях кварка... Меньше затрат на переучивание персонала, не надо переделывать шаблоны и т.д и т.п.
А проекты "с нуля" сейчас чаще всего на InDi строят.
Кваркофилы, прошу не обижаться. Такова объективная реальность...
 
Ответ: InDesign V&S (против) QuarkXPress


Не по теме:
Самая активная тема в разделе однако.
 
Ответ: InDesign V&S (против) QuarkXPress

Все про картинки да про картинки...

В индюке напрягает отсутствие стилевой таблицы для H&J (соответственно встраивание оных в стиль параграфа) и невозможность привязать стиль карактера к стилю параграфа.
 
Статус
Закрыто для дальнейших ответов.