Ответ: Использование LZW-сжатия.
налицо путаница между "внедрение как есть" (например, в случае eps) и
"обработка исходных данных и, на основе результатов, копирование из входного потока в выходной отдельных участков"
тиф -- это header, плюс IFD (грубо говоря, таблица тэгов), плюс данные, на которые могут ссылаться отдельные записи таблицы. В том числе, собственно данные о цвете пикселов сплющенного варианта (уж коль скоро разговор о слоеных тифах), как правило разбитые на strip'ы, каждый из которых как правило упакован (сжат)
что делают утилиты о которых Вы говорите? Они формируют в выходном ps-потоке словарь (dictionary) имиджа, значения для ключей которого извлекаются из соответствующих полей (записей) IFD, или вычисляются на их основе. Такие как width, height, imagematrix и т.д. Нам интересен ключ ImageSource. В качестве него указывается процедура, последовательно, в цикле (число повторений которого равно числу стрипов), считывающая из ps-потока данные, размещаемые после словаря. Данные, как были сжаты в стрипе (в тифе), так и переносятся в ps-поток, а в процедуре указывается соотв. декодер (например lzw или ccitt). Для ascii-совместимости данные обрабатываются еще ascii85 фильтром.
Абсолютно то же самое делают dtp-программы, при выводе в постскрипт заверстанных тифов. Но только менее эффективно, как по причине "дубовости" кода больших проектов, так и потому, что стрипы разжимаются и склеиваются в один поток, который, в зависимости от опций вывода ps, может быть далее сжат (напр. RLE) и/или закодирован в ascii. Работа енкодеров-декодеров lzw, ccitt и др. дает однозначный результат, вопрос только времени записи в постскрипт. Главное, как в случае например кварка, так и например tiff2ps, это декодирование IFD тиффа.
надеюсь, Вы понимаете, что говорить "TIFFы инкапсулируются в постскрипт один в один" и ставить их в этом смысле в один ряд с EPS, неверно. Еще раз, то, что получилось из тифа в постскрипте, есть результат работы входного фильтра приложения, а никак не копирование "как есть".
