Так он еще и печатает?!.

Данный текст предложен программистом, волею судеб оказавшимся перед необходимостью осуществлять качественную печать из своих программ в среде Linux.

[Владимир Попов]

Данный текст предложен программистом, "волею судеб" оказавшимся перед необходимостью осуществлять качественную печать из своих программ в среде Linux. Автор не является ни Linux-гуру (опыт программирования под этой ОС - не более года), ни "чайником" (опыт программирования в целом - более 20-ти лет). Поскольку программисты составляют все-таки меньшую (чуть не сказал - лучшую) часть пользователей компьютеров, то автор попытался сделать этот материал полезным обычному, "среднестатистическому" пользователю. По крайней мере - небезынтересным для него.

Что за проблемы такие, спросит неискушенный читатель, печатавший только из MS Office. Раз на экране есть - долго ли перенести на бумагу? К сожалению, иногда - долго. Забудем (по крайней мере, в рамках данной темы) об алфавитно- цифровых терминалах и таких же печатающих устройствах. Там проблем действительно не было. Если коды символов, используемые терминалом и АЦПУ, одни и те же - соответствие будет. По содержанию, как минимум. Однако, где это все сейчас? У кириллицы только стараниями MicroSoft три кодировки (cp866, win1251 и unicode).
А есть еще и разрабатывавшаяся как стандартная koi8. Да и глазу, привыкшему к разнообразию в графических средах, страница АЦПУ кажется неестественно "пресной". Производители принтеров идут навстречу пользователям: и вот уже раритетом смотрится матричный принтер - последний из принтеров, для которого графический режим - вторичный. Для лазерных же и струйных принтеров, наиболее широко распространенных в наше время, графический режим - единственно возможный. Казалось бы: и прекрасно.

На экране у нас тоже графика: перенести - и дело с концом. Не получается. Несложные расчеты показывают, что попытка поставить точку принтера в прямое соответствие с пикселем на экране превратит изображение 800х600 в картинку 6.7х5см (/300*2.5). И это - для принтера, печатающего с разрешением 300dpi (dot per inch - точек на дюйм), что совсем не "шик" по нынешним временам. Маловато будет. Это и есть "первопричина" всех проблем печати: принтер создает изображение с намного большей разрешающей способностью, чем видеоадаптер.

Преобразование растрового (точечного) изображения на экране в аналогичное для принтера оказалось неприемлемо сложным для достижения удовлетворительного качества. Другими словами, для вывода на принтер требуется еще одна параллельная система визуализации. И она существует. Разная в разных операционных системах. Поскольку тема наша - печать под Linux, то к рассмотрению подсистемы печати UNIX и перейдем.

Оставим в стороне "нижний" слой подсистемы печати, обеспечивающий передачу потока байт от ядра ОС в параллельный порт или на сетевой принтер. lpd (line printer daemon) не является предметом обсуждения, а инсталляция всех известных мне дистрибутивов корректно выполняет все операции по его настройке. Не будем обсуждать вообще так называемое "spooling software". Хоть это и чрезвычайно важный и довольно бурно развивающийся в последнее время компонент подсистемы печати, но трудностей с ним я не встречал. Возможно - везло.

Получение же качественной печати, да еще с кириллицей, да из разных приложений, к сожалению, "само собой" получается не всегда. Очевидно, что дело здесь не в трудностях передачи двоичного потока в порт. "Драйвер неправильный..." - констатирует недавний пользователь MS Windows, и будет прав в том, что неверно работает принтер-специфичная управляющая часть подсистемы печати. Другими словами - управление принтером, а не параллельным портом.

Со времен так называемой "революции настольных издательских систем" 80-х в качестве стандартного языка управления принтером постепенно утвердился Postscript. И не только в UNIX-среде, а и в издательском деле вообще. Подход прост: все, что можно напечатать, описывается с помощью специального языка программирования (Postscript), принтер же должен этот язык понимать. Здорово. Не имеет значения, какой именно принтер, не имеет значения, какая ОС: был бы вывод в виде Postscript-файла и принтер, способный выполнять программу на этом языке. Adobe Systems, Inc., изначально разработавшая стандарт на Postscript, открыла его для свободного распространения. Программное обеспечение, генерирующее Postscript-файлы в качестве выходных, стало развиваться лавинообразно, в том числе - и OpenSource. Принтера тоже не заставили себя ждать, но... Они оказались стабильно дороже своих не-Postscript аналогов. На $100 в среднем. Оно бы и ничего, как будто, для коммерческих реализаций UNIX, но вот для Linux... Хороша система печати свободно распространяемой ОС, требующая для своей реализации заведомо более дорогой принтер.
Обидно, понимаешь... Решение появилось быстро: ПО, преобразующее Postscript в команды уже конкретного принтера. Заумно? Но драйвера для MS Windows делают практически ту же работу, с той лишь разницей, что между ними и ОС нет стандартизированного языка описания заданий принтера. Суть - та же. Пора, кажется, перейти к конкретным компонентам реализации этой системы в Linux.

Персонаж первый и самый главный - ghostscript (gs). Все версии AFPL Ghostscript доступны для персонального использования, но существует ограничение для коммерческих дистрибутивов Linux. Для комплектации в составе последних доступен GNU Ghostscript, представляющий собой тот же gs, только версией пониже и с другим лицензионным соглашением. На сегодняшний день можно загрузить версию AFPL Ghostscript 7.0, тогда как версия GNU Ghostscript - 5.5. Эта же версия поставляется с большинством дистрибутивов. ghostscript, собственно, - это как раз то, что позволяет нам не покупать Postscript-принтер. В составе - внушительный набор фильтров - аппаратно ориентированных модулей, позволяющих получать изображение на различных устройствах. Устройствах, а не принтерах, поскольку ghostscript может обеспечить вывод на любое графическое устройство.

Именно gs присутствует в качестве фильтра в /etc/printcap - конфигурационном файле lpd. Опции запуска gs в качестве фильтра определяются типом принтера. Посмотреть - стоит, а модифицировать - пока не нужно: вероятнее всего и эти настройки процесс инсталляции выполнил корректно. Разве что принтер "чудит" (гонит пустые страницы, псевдографику и т.п.). В этом случае стоит вернуться к процедуре конфигурирования принтера и выбрать фильтр "соседней" модели, лучше - проще. Если вам захочется получить "максимум" от своего принтера, то к настройкам gs можно вернуться позже: вероятно, существуют patches и для вашего принтера, и для вашей версии gs, можно попробовать более позднюю версию и так далее.

Рекомендации - по выше приведенным адресам. Только нужно это тогда, когда вам не хватает более высокого разрешения или поддержки каких-то особенностей вашего принтера, наличествующих, но не поддерживаемых имеющимся ПО. Для начала я все-таки советовал бы получить нормальную печать с кириллицей хотя бы для разрешения 300dpi. Кстати, проблемы с кириллицей, вероятнее всего, вообще не имеют отношения к выбранному фильтру ghostscript.

Персонаж второй - ghostview (gv). Производитель - тот же. gv - приложение Х11, назначение которого - принять вывод ghostscript и вывести изображение на экран. Таким образом, мы получаем инструмент, обеспечивающий "print preview" для любого приложения, генерирующего PostScript-файлы. Хорошая иллюстрация UNIX-идеологии и существенная экономия бумаги. В общении с gv вы уже точно сможете определить, проблемы ваши связаны с выбором фильтра принтера или работой gs в целом. Видите, но не получаете на печати - попробуйте другой фильтр (выберите другой принтер), не видите ничего "путного" - продолжаем разбираться с системой печати.

Персонаж третий - PostScript-фонты. Самый сложный. Почему? По причине отсутствия стандарта на дерево каталогов как в UNIX вообще, так и в Linux в частности. Мало того. Структура каталогов меняется от версии к версии даже в пределах одного дистрибутива. И когда уже окончательно утвердится FHS (Filesystem Hierarhy Standard), о поддержке которого заявили все составители дистрибутивов? Пока же производители ПО OpenSource, как правило, не ориентируются на определенный клон UNIX. Тем более - на определенный дистрибутив Linux. Если вы компилируете пакет сами, вам, возможно, будет задан вопрос о местонахождении каталогов, если же инсталлируете бинарный пакет (rpm, etc.) - его компоненты окажутся там, где посчитал нужным составитель.

Поскольку PostScript-фонты используют очень многие приложения, то файлы фонтов могут оказаться где угодно. Очень часто - не там, где их будет искать ghostscript. Результат - очевиден. От не соответствующего замыслу внешнего вида распечатанного документа - до искажения или отсутствия фрагментов текста, требующего, в соответствии с PostScript-файлом, того самого фонта, который не смог загрузить ghostscript. Положение усугубляется тем, что, по крайней мере, часть документов включает кириллицу, а некоторые дистрибутивы не имеют в каталогах, сканируемых по умолчанию ghostscript, фонтов с кириллицей.

Обидно то, что в дистрибутиве или даже на диске эти фонты наверняка есть. Преодоление этих трудностей нужно начинать с анализа файла Fontmap в каталоге ghostscript. Местонахождение самого каталога, предположительно, - /usr/share/ghostscript/version. В файле перечислены имена фонтов в той нотации, в которой допускается их использование в PostScript-файлах (имена после слэш, "/"), их синонимы (aliaces) и, собственно, файлы фонтов. Пути к файлам не указаны. Если вы не использовали предлагаемые руководством средства принудительной "ориентации" ghostscript (параметры командной строки и переменные окружения), то gs будет использовать "пути по умолчанию", заданные при компиляции.

Таким образом, возможностей для ошибки - более чем достаточно. Если печать (и просмотр) посредством ghostscript представляют для вас интерес, я бы рекомендовал полную ревизию PostScript-фонтов и файла Fontmap. Тем более, что в этом нет ничего трудного: имена файлов так называемых "регулярных" фонтов перечислены в Fontmap, маски файлов, содержащих фонты: *.pfb, *.pfa, *.gsf. Находящиеся в каталогах фонтов файлы fonts.dir содержат описание фонтов в данном каталоге. На этом этапе, раз уж вам пришлось так углубиться в тонкости работы ghostscript, я бы порекомендовал вооружиться простеньким PostScript-файлом. А хотя бы и showfont.ps Дилана Макнами. Теперь можно: переписать файл фонта, заведомо обеспечивающего вывод кириллицы в каталог, используемый ghostscript при поиске фонтов (скорее всего, это каталог, в котором больше всего файлов с расширением "pfb"), внести имя этого файла и, соответственно, фонта в Fontmap, изменить в файле showfont.ps имя демонстрируемого фонта (метка /TSTN) на только что внесенное вами в Fontmap и просмотреть его с помощью gv. Таким образом, вы узнаете, нашел ли gs запрошенный фонт и (если нашел, конечно) как символы этого фонта выглядят. Если не нашел, это значит: переписали вы его не в тот каталог, где gs ищет фонты. Выхода, очевидно, два: найти методом эксперимента нужный каталог или "навязать" gs путь поиска. Выбор - за вами. Если понятно все вышеизложенное, то вы становитесь "хозяином" положения: в зависимости от потребностей можете вносить в Fontmap необходимые фонты, а можете менять их переназначения - секция Aliaces: например, alias /Courier, изначально указывающий на /NimbusMonL-Regu (которому, в свою очередь соответствует файл (n022024l.pfb)) меняем на вставленный нами, скажем, /CourierISOC (соответствующий файл - (crr35__i.pfb)). Если задача - в основном печатать файлы, PostScript-содержимое которых вне вашего контроля, - подберите соответствующий фонт и измените Aliaces. Если PostScript-файл генерируется под вашим контролем - просто ссылайтесь в нем на нужный вам фонт. Разумеется, не забыв при этом описать его в Fontmap.

Почему так сложно? Да просто не сложился пока что единый подход получения кириллицы в PostScript. Кто-то из авторов (файла или ПО, генерирующего PostScript-печать) рассчитывает на наличие у вас набора фонтов с кириллицей, кто-то - на модифицированные оригинальные фонты, но практически никто не хочет удовлетвориться моноширинным Cyrillic, известным gs без всяких дополнительных манипуляций. Тем более, что вышеупомянутый Cyrillic хоть и известен (упоминается в Fontmap), но совсем не всегда присутствует в дистрибутиве.

Ну, и как к этому всему относиться пользователю? Да, в общем, спокойно, я думаю. Во-первых, потому, что не так уж все и сложно, мне кажется. Во-вторых, потому, что есть надежды на улучшение: необходимость стандартизации все больше признается в мире OpenSource. В-третьих, раз проблема в большой степени сводится к проблеме фонтов, то не такая уж это редкость: подобные были и с MS Office при переходе к unicode, и продолжают существовать в Интернет в связи со множественностью кодировок. Если уважаемый пользователь MS Windows решил в свое время проблемы сохранения внешнего вида документов, подготовленных в "старом" MS Office, и сам конвертировал true-type фонты из старого формата в unicode, то при необходимости он и с Fontmap разберется. Нет сомнений. Случится ли только такая необходимость?... Но это уже другая тема.

Теперь обратимся к разработчику. Здесь картина несколько иная. Прежде всего потому, что для него все вышеизложенное уж и подавно не должно показаться сложным. Возможность же получить высококачественную печать из своих приложений явно стоит затрат времени. Что же может программист, используя особенности системы печати UNIX? Без преувеличения можно сказать - всЈ. ВсЈ в этой сфере, поскольку в его распоряжении оказывается открытый язык программирования, признанный достаточным практически на всех уровнях издательского дела. Подчеркну: не делопроизводства (см. MS Word), а именно издательского дела. Другое дело, нужны ли ему эти возможности. Коснемся вкратце простейших.

Язык PostScript достаточно прост, и печатать разными фонтами, начертаниями, размерами можно, лишь чуть-чуть познакомившись с его принципами и синтаксисом. Вполне достаточно, скажем, курса "PostScript First Step" - 400к с иллюстрациями, примерами и справочником. Правда, если захочется картинок, фонов и draft-текстов (блеклые буквы в качестве фона), то получасовым знакомством с этим языком не отделаться: он вполне полнофункционален и, значит, не так уж прост. Если все-таки хочется, а времени на изучение PostScript нет, то существует довольно большой список программ-генераторов PostScript из различных файлов. Из ascii - прежде всего. Самые простейшие позволяют, отказавшись от минимальных познаний PostScript, задавать фонты, размеры и прочие необходимые для качественной печати "мелочи". Дальше - больше, вплоть до генераторов, поддерживающих собственные языки разметки и эффектов печати. Из входящих, как правило, в дистрибутивы лучший пример первых - trueprint (Lezz Giles)... таких красивых листингов у меня еще никогда не было. Пример вторых - GNU a2ps, который часто дополняется еще и с фонтами, содержащими кириллицу. Такие программы часто используют так называемые "метрики" фонтов - файлы с расширением "afm". Оно и понятно: для того, что бы красиво отформатировать текст нужны характеристики фонта, которым этот текст будет выводиться. Лучше, на мой взгляд, держать все фонты и метрики в одном каталоге, указав его программе-генератору в качестве параметра. Как - придется посмотреть в документации конкретного генератора. Обратите внимание, что список метрик часто считывается из файла font.map, создаваемого, в свою очередь, командой "mkafmmap *.afm". Список этот связывает названия фонтов с именами файлов, эти фонты содержащими. Обычно, всЈ это описано в документации генератора, нужно только не забыть прочитать.

В заключение поделюсь двумя лучшими из известных мне ссылок по этой теме. Первая - "глобальный" ресурс по печати в Linux - LinuxPrinting.org. Вторая - Internet Resources for POSTSCRIPT & GHOSTSCRIPT. Страница практически не содержит оригинальных данных, зато предоставляет практически исчерпывающий список ссылок на "около-PostScript" ресурсы.

Успехов.



[Источник Softterra.ru]

[ опубликовано 22/10/2001 ]

Владимир Попов - Так он еще и печатает?!.   Версия для печати