Добрый день всем. Вот такая головоломка:
Необходимо массово отправлять на печать, на заранее определенный принтер, сканы документов (файлы формата .tif), хранящиеся в BDS.
Всё бы ничего, но есть ограничения:

1) задание на печать необходимо формировать минуя Frontend (например, пришел Idoc - сразу распечаталось несколько сканов). Таким образом, класс CL_GUI_ECL_2DVIEWER не подходит; OLE-технологии тоже.
2) файлы многостраничные (т.е. один tif-файл может содержать сразу несколько страниц).
3) система 4.7

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

Есть ли у кого идеи, в какую сторону ещё можно копнуть?

см программу RSTXLDMC

Данная программа загружает файл с Frontend-а и сохраняет в виде SAPSCRIPT-текста, аналогично транзакции SE78. Но это только первый шаг. Следующим шагом будет вставка загруженной картинки в SAPSCRIPT формуляр (к слову, у меня файлы уже загружены в BDS - так, что это не совсем мне подходит, но тем не менее...).

Итак (первый шаг), Те TIF-файлы, с которыми предстоит работать, невозможно загрузить ни указанной Вами программой, ни тр.SE78 - выдает ошибку TIFF format error: No baseline TIFF 6.0 file, причиной чему, как я думаю, является многостраничность файла (при этом, файл корректный, т.к. любой другой просмотровщик открывает без проблем).
Однако, если обработать этот файл с помощью графического редактора, оставив одну страницу, то загружается нормально (но для меня, как вы понимаете, это уже не приемлемо).

Далее (второй шаг), я пытаюсь загруженный файл завернуть в SAPSCRIPT-форму посредством связки Ф.М. 'SAPSCRIPT_GENERATE_BMP_COMMAND' и Ф.М.'PRINT_TEXT' (так, как показано здесь) - получается пустой формуляр (без картинки). Я экспериментировал с разными размерами TIF-файлов, но, как я понимаю, такой трюк возможен только с файлами BMP.

Может быть есть ещё какие-нибудь идеи?

1)
http://www.fileformat.info/format/tiff/corion.htm

в случае с одной страницей, скорее всего отсутствуют сегменты IFD (image file directory),
если они присутствуют, нужно вручную страницы разводить в отдельные бинарники,
для этого можно сделать diff обычного и многостраничного файлов в бинарном виде,
чтобы понять как разбирать, или просто в hex редакторе подсмотреть.
т.е. нужно разодрать многостр файл по ifd, выкинуть заголовки ifd, склеить каждую
страницу с заголовком одностраничного файла и кормить se78, получая длинные тексты

2)
кажется слишком усложнили, sapscript должен выводить длинный текст
без всяких предварительных преобразований,
только что загрузил одностраничный файл (BCOL, dpi 150) в se78 в длинный текст и в so10 его видно
по кнопке Предв просмотр перед печатью, параметры для PRINT_TEXT подсмотрите в отладке

Действительно, так. Правда есть свои тонкости: IFD и Данные изображения для каждой страницы не обязательно следуют в файле друг за другом, а могут быть в любом порядке, и при этом, связаны ссылками друг на друга. Здесь поверхностным анализом файла не обойтись, придется выполнять полноценный парсинг.
Поэтому, вместо отдельной предварительной подготовки файла перед загрузкой в тр.SE78, лучше будет вклиниться в сам алгоритм парсинга, выполняемый тр.SE78 (ведь TIF и BMP -картинки хранятся в текстах не "как есть", а переведенные во внутренний формат SAPSCRIPTа - так называемый BM_FILE). Это не очень сложно, но этим дело не ограничится.

Я выяснил, что ошибка TIFF format error: No baseline TIFF 6.0 file появляется ещё и потому, что тр.SE78 не умеет парсить файл с LZW-компрессией. Это очень прискорбно, поскольку данная опция используется в подавляющем большинстве TIF-файлов (т.к.уменьшает их размер файла в 2-3 раза).
Таким образом, в процедуру парсинга исходного файла потребуется внедрить ещё и алгоритм LZW-декомпрессии. Данный алгоритм в общем-то не сложный, но есть там ряд подводных камней... Пока не знаю, готов ли я к таким "подвигам", т.к. задача не приоритетная. Ещё раз, спасибо за совет.

другой подход - если as на aix или suse ,проверить присутствует ли утилита convert (libtiff),
если нет, то попробовать найти или собрать бинарник с помощью базиса (придется
на тесте и продуктиве ставить), этой утилитой можно преобразовать многостраничный tiff
в кучу разных вариантов (pdf, ps, jpg, tiff и др.)

Игорь, а сканы обязаны быть в tiff? Если это сканы с какого-нибудь более-менее современного МФУ или сканера, то там обычно выбор из форматов для сканирования есть и среди них присутствует PDF. Может сразу в PDF и сканировать?

Совсем альтернативный подход - реализовать печать не средствами SAP, а средствами ОС (или специального приложения/сервиса).
Например, при получении IDOC вываливать в определенную папку нужные TIFF многостраничные, затем делить их на отдельные одностраничные (с печатью которых проблем меньше), например, натравливая на них через вызов ОС это, а затем отправлять на печать полученные файлы через другую команду ОС.

Хотя ощущение костылей меня не покидает.

сканы уже давно присутствуют в системе и их довольно много (сотни, а может и тысячи). Это всяческие сертификаты соответствия на каждый из видов продукции и др.документы.
теоретически, можно поменять регламент и сканировать в PDF, а те сканы, что есть - сконвертировать... но что это даст? Ведь в 4.7 нет ADS (Adobe document system) и в спул поставить PDF-документ я не представляю как. С tif-файлами есть хоть какая-то "зацепка".
Примерно так сейчас и реализовано... файлы выгружаются на frontend и (посредством OLE) открываются в MS Picture manager-е, посредством чего и отправляются на печать.
Но пользователей не устраивает необходимость каждый раз делать это вручную (печатать приходится печатать много раз за день), а также, временами возникающие сбои при печати (т.к. файлы довольно "увесистые" и идут на печать по полсотни подряд). Пожелание пользователей - просто забирать готовые отпечатки с определенного принтера, и всё... (а печать должна осуществляться автоматически по факту прихода очередного IDOC из др.системы).
К сожалению, as на винде... а базисники - в другой стране и прямой контакт с ними исключен (общение возможно только посредством руководства, через заявки, которые могут рассматриваться месяцами). С полномочиями тоже беда.
В общем, поковыряв гр.функций STXBITMAPS, путем частичного её копирования и переработки, я набросал отчет, который анализирует не один, а все имеющиеся IFD в файле, и таки, отправляет в спул многостраничный TIF-файл (до алгоритма декомпрессии пока дело не дошло, экспериментирую с несжатыми файлами). Спул на предпросмотре выглядит именно так, как нужно и я хотел было уже обрадоваться... НО при попытке распечатать такой спул выдается ошибка: OTF module: Page buffer (80*1000 entries) is too small и всё, приехали (( . Замечу, эта ошибка выходит при работе со сканом, имеющим размер А4 и разрешением 300 dpi... если же уменьшить разрешение этого файла до 150 dpi - ошибки не возникает, всё печатается нормально!
Возможно ли как-либо увеличить этот страничный буфер? и как?

Игорь, я имел ввиду не печать средствами ОС на стороне клиента, а печать средствами серверной ОС (Windows как я понял), на которой работает SAP. Другое дело, что прочитав про то, как у вас "организовано" взаимодействие с базисом, чую, что этот способ тоже будет трудно реализовать, так как в любом случае нужно будет разруливать вопросы настройки принтеров на сервере.
Ну, тогда другой вариант (не менее извращенный) - поднимите у себя в офисе какой-нибудь локальный сервер (наверняка есть такой уже), на котором расшарьте папку (для доступа саповского сервера), настройте упоминавшийся ранее imagemagic, и слежение за папкой, из которой должны печататься файлы.
1) Саповский сервер положил файлы во входящую папку
2) Скрипт обработал их imagemagic и сложил в исходящую папку
3) Другой скрипт из исходящей папки отправил их на печать (можно, наверное, это и средствами САПа сделать, но как-то смысл теряет)

Вот тут похожее обсуждали. Ну как я понял.

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

Из приведенного обсуждения можно выделить две идеи:
1) поставить PDF в спул. К сожалению, попробовать это сделать предлагается с помощью гр.Ф.FPCOMP, но в нашей системе (4.7) она не существует... и это не говоря о том, что надо как-то TIF сначала конвертировать в PDF.
2) отправить TIF по электронной почте, которую мониторит офисный принтер (технология ePrint у HP) - вот это очень интересная идея! довольно просто в реализации, тем более, что наш принтер поддерживает эту технологию (дополнительного оборудования не требуется). Обсужу это с руководством.
Пока не ясно, поддерживает ли софт ePrint многостраничный TIF... возможно использовать конструкцию с imagemagic-ом, которую предложил peper-