[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]О почте и т.п.

[Aleksey Novodvorsky]

Maksim Otstavnov wrote:

> H
>
> Опыт показывает, что если на каком-то этапе планирования мы получаем
> необычно высокий прогноз трудозатрат, мы _уже_ где-то ошиблись - на этапе
> постановки задачи и/или ее декомпозиции.
>
> Я по совету AEN заглянул, что там в gnome-print (полагая ситуацию
> типичной), и не вполне понял, к чему это. В смысле, к чему приложениям
> такая библиотека.

Она нужна для того, чтобы не писать свой генератор ps для каждого приложения. В
qt/KDE соответсвующая подсистема есть в qt, в Gnome-- gnome-print.

>
>
> Насколько я понимаю, "печать" на сегодня сводится а) к созданию
> ps-файла и b) его корректной интерпретации - железом/firmware принтера
> или программным рендером типа ghostscript.

Задачи b) не существует, если a) решена.

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

Генерация ps -- весьма сложная задача.  gnome-print претендует, напримир, на
гереацию ps для надписей вдоль кривых заденным шрифтом. Добавьте сюда возможно
бОльшую корректность рендеринга.
Что касается Mozilla, то она не имеет на сегодняшний момент сколько нибудь
универсальной системы печати, пригодной даже для создания ps с несложного html.
Ее основой является самая худшая из всех систем печати, взятая из netscape.

>
>
> Что касается (к примеру) Мозиллы, то ее (его?) дотягивание до i18n -
> это, конечно, не точечное воздействие, но все же локальная задача.

Дотягивание того, что есть -- локальгая задача, но результат будет также
локальным.

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

Ее делает один выделенный человек уже гораздо больше года.

>
>
> AB> Проблема организационная, согласен. Но, главным образом, эта
> AB> проблема в том, что вопросам сосуществования различных языков и
> AB> алфавитов при преподавании Computer Science ни здесь, ни в
> AB> Latin1-е не придается надлежащего внимания.
>
> Все же, этому место не в computer science, а в учебниках по системам
> разработки, наверное.

Да, конечно.

>

Об "особеностях национального ps". Их, конечно же, просто нет. Есть система имен
глифов от Adobe, которая сейчас хорошо корреспондирует  с UCS. И все. Но
существует понятие вектора кодировки, в котором может быть 256 символов. Это
твектор -- просто словарь ps документа. По старой привычке все берут стандартный
словарь -- ISOLatin1, и из шрифта берутся при этом глифы с соответствующими
именами. Таким образом, в этом случае, если русский шрифт у вас с правильными
именами русских глифов (afiiXXX), то на месте русских букв будет пусто, а если
хакнутый (то есть с рускими глифами под Latin1-именами), то при попытке
напечатать таки Latin1, вместо символов >=128 будут русские буквы.
Корректно генерит  ps qt, но их  подсистема печати не учитывает метрики шрифтов,
то есть -- как повезет. Учет метрик шрифтов настолько нелюбимая программистами
задача, что эти метрики часто зашиваются внутрь программ, и. естественно, не
русские и даже не Latin-2. Происходит это из-за нежелания (неумения) писать
рендеринг с произвольными метриками. Кстати, ошибки в рендеринге на печати
свойствены не только Unix-софту, но и IE, например. Происходит привязка к
"стандартным" ps-шрифтам  из комплекта gs, в первую очередь Nimbus*.
Дело можно значительно упростить, если вместо encoding vector использовать
словарь соответствия USC и имен глифов Adobe, а последние вызывать по именам, а
не по номерам в векторе кодировки. Это, правда, несколько замедлит интерпретацию
ps. Другой вариант, который пытаются реализовать в драйвере ps2 из gnome-print --
создавать в генерируемом ps виртуальный шрифт Type0, что не более эффесктивно и
более сложно, и на чем они  запутались.

Замечу в скобках, что национальные проиводители шрифтов из Paratype делают
Unicode-шрифты с нестандартными именами глифов. Но это отдельная история.

Rgrds, AEN