[mdk-re] Re: [mdk-re] Re: [mdk-re] Re: [mdk-re] Re: [mdk-re] Re: [mdk-re] Re[2]: [mdk-re] Re[2]: [mdk-re] Re[2]:[mdk-re] Re[2]: [mdk-re] Re[2]: [mdk-re] Re[2]: [mdk-re] Re[2]: [mdk-re] Re: [mdk-re]О почте и т.п.

Alexander Bokovoy =?iso-8859-1?q?ab_=CE=C1_avilink=2Enet?=
Вт Янв 2 02:13:01 MSK 2001


On Tue, Jan 02, 2001 at 01:42:52AM +0300, Aleksey Novodvorsky wrote:
> > Насколько я понимаю, "печать" на сегодня сводится а) к созданию
> > ps-файла и b) его корректной интерпретации - железом/firmware принтера
> > или программным рендером типа ghostscript.
> 
> Задачи b) не существует, если a) решена.
Да, задача b) может считаться решенной apriori -- открытый интерпретатор
PostScript-а достаточно точно соответствует стандарту при правильных
входных данных. А вот формирование правильных входных данных пока еще
не слишком распространено.

> > Про (b) я просто не в курсе - AEN обещал подумать над тем, чтоб нас
> > всех просветить об особенностях национального постскрипта. Я этого не
> > знаю даже на пользовательском уровне - просто в голову не приходило
> > ничего кириллицей печатать ;)
Список таких примеров очень широк -- банальная распечатка документа из
офисного приложения, веб-страницы, текста программы, качественной
иллюстрации с надписями по сложным кривым и так далее. Добавьте точное
позиционирование, необходимое для печати документов на бланках (или
самих бланков).

> > Что касается (a) мне кажется, что 90% приложений _не_ нужно этого
> > делать. Нужно выводить данные в *ML и оставлять его рендеринг
> > соответствующей программе - принт-подсистеме Мозиллы, к примеру. 10
> > остающихся процентов - это собственно preprint-приложения, которые -
> > отдельная песня. Они всегда были отдельной песней, причем на всех
> > платформах.
> 
> Генерация ps -- весьма сложная задача.  gnome-print претендует, напримир, на
> гереацию ps для надписей вдоль кривых заденным шрифтом. Добавьте сюда возможно
> бОльшую корректность рендеринга.
... в случае вывода шрифтов как кривых. Для внедряемых шрифтов важно оперирование
реальными векторыми шрифтами и их характеристиками, а не конвертирование их
в Type3 с растрированием под только одно разрешение.

> > Наверное, не требующая человеко-года программера экстра-класса. (Это
> > предположение, я не лазал и не смотрел).
> Ее делает один выделенный человек уже гораздо больше года.
И результат местами очень плачевный, если речь идет о gnome-print.

> > AB> Проблема организационная, согласен. Но, главным образом, эта
> > AB> проблема в том, что вопросам сосуществования различных языков и
> > AB> алфавитов при преподавании Computer Science ни здесь, ни в
> > AB> Latin1-е не придается надлежащего внимания.
> > Все же, этому место не в computer science, а в учебниках по системам
> > разработки, наверное.
> Да, конечно.
Проблема в том, что сейчас этого нет ни там, ни там, этого вообще нигде
в учебном процессе нет. К тому же, если быть до конца точным, то
современные стандарты на языки программирования определяют (не
полностью, правда), механизмы оперирования символьной информацией с
учетом Unicode (C99, ANSI C++ latest draft). И это касается также POSIX
и XPG/2. Методы, описываемые в них достаточно общны для того, чтобы
успешно абстрагироваться от "национальных" особенностей платформ и
компиляторов.

> Об "особеностях национального ps". Их, конечно же, просто нет. Есть система имен
> глифов от Adobe, которая сейчас хорошо корреспондирует  с UCS. И все. Но
> существует понятие вектора кодировки, в котором может быть 256 символов. Это
> твектор -- просто словарь ps документа. По старой привычке все берут стандартный
> словарь -- ISOLatin1, и из шрифта берутся при этом глифы с соответствующими
> именами. Таким образом, в этом случае, если русский шрифт у вас с правильными
> именами русских глифов (afiiXXX), то на месте русских букв будет пусто, а если
> хакнутый (то есть с рускими глифами под Latin1-именами), то при попытке
> напечатать таки Latin1, вместо символов >=128 будут русские буквы.
> Корректно генерит  ps qt, но их  подсистема печати не учитывает метрики шрифтов,
> то есть -- как повезет. Учет метрик шрифтов настолько нелюбимая программистами
> задача, что эти метрики часто зашиваются внутрь программ, и. естественно, не
> русские и даже не Latin-2. Происходит это из-за нежелания (неумения) писать
Вот вам и пример отсутствия соответствующего образования. Как мне
признавались многие программисты, как здесь (в Беларуси и России), так и
"там" (круг был достаточно широк -- США, Канада, Голландия, Франция,
Германия, Финляндия, Швеция, Польша), эта тематика, конечно, важна, но
для них ресурсоемка для изучения. Причем "тамошние" товарищи
подытоживали в стиле "как было бы хорошо, если бы везде была бы только
Latin-1". И это люди, уже получившие диплом software engineer.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |    Aurora R&D team 
Minsk Linux Users Group |    www.minsk-lug.net    |  www.aurora-linux.com  
   IPLabs Linux Team    |     linux.iplabs.ru     | Architecte Open Source
-- A rolling stone gathers momentum.




Подробная информация о списке рассылки community