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

[Alexander Bokovoy <ab@avilink.net>]

On Wed, Jan 03, 2001 at 01:06:59AM +0300, Maksim Otstavnov wrote:
> Wednesday, January 03, 2001, 12:50:24 AM, Aleksey wrote:
> 
> >> Я _этого_ и не понял: зачем приложению генерировать ps...
> 
> AN> Вот именно, что этого делать не нужно. Но тогда нужна
> AN> универсальная библиотека. Если ее нет, то что же делать
> AN> приложению?
> 
> Использовать то, что есть. Сегодня HTML хватит для 90% приложений. А
> html2ps писать _все равно <sigh> придется_.
Безусловно. Только вот тем приложениям, которые рисуют (а это не только
пресловутые растровые и векторные редакторы, а разнообразные научные
программы в том числе), возможностей HTML будет маловато. В частности,
SVG до сих пор только Candidate Recommendation, и уже сейчас есть
комментарии о том, что, в частности, поддержка вывода текста в нем
совсем по-детски спроектирована. Например, требования нередактируемости
глифов и отсутствие заранее информации о их размерах (bounding box)
осложняют библиотеку трансформации SVG в постскрипт, отсутствие
расположения текста вдоль кривой делает нереализуемыми многие эффекты
из DTP (и не только -- в тех же научных, обучающих, картографических
программах расположение текста вдоль кривой не есть прихоть).
Это только один пример.

> AN> Я уже писал. i18n можно сделать прозрачным, и примеры этому есть.
> 
> Я немного не про это: помимо i18n должны быть очень существенные
> преимущества, чтобы ей начали пользоваться.
Вы имеете в виду библиотеку печати? Единый кроссплатформенный интерфейс
и отсутствие необходимости самостоятельного формирования печатной формы
(по аналогии с микроэлектроникой) стоят многого.

> >> Как курьезный пример стоит упомянуть, что в MS, при всей ее
> >> компактности и в количественном отношении (по OSS-меркам),
> 
> AN> ??? Не думаю, что MS компактна по меркам OSS. Вы сильно
> AN> преувеличиваете количество реальных разработчиков Open Source.
> 
> Я не думаю, что сейчас у них количество _программистов_ в каком-то
> проекте превышает сотню.
В OpenSource проектах редко количество программистов превышает несколько
десятков, пик, скорее, приходится на 3-10. Конечно, чем крупнее проект,
тем больше программистов, но реально работающих над кодом достаточно
мало -- остальные обеспечивают инфраструктуру, иногда эффективно, иногда
-- не очень.

> >> Я _этого_ и не понял: зачем приложению генерировать ps...
> AB> А что оно должно генерировать? Ведь должно генерироваться что-то, что
> AB> далее может быть обработано подсистемой управления печатью.
> 
> Я, видимо, все же очень косноязычен. Попробую еще раз. Для решения
> задачи корректной печати обсуждаются два подхода:
> 
> а) библиотека печати,
> 
> б) некий промежуточный формат.
> 
> Я думаю, никто не будет спорить, что синтаксис/семантика набора
> системных вызовов в первом случае и самого формата во втором будут
> сопоставимыми по сложности при сопоставимой экспрессивной силе.
> 
> Я аргументирую в пользу второго (отнюдь не считая аргументы ни
> бесспорными, ни решающими):
> 
> 1) можно опереться на существующие языки разметки, а не выдумывать все
> заново,
> 
> 2) можно сузить потребную полосу пропускания на выходе приложения, что
> весьма желательно для топологий с выделенным принт-сервером или с
> аутсорсингом принт-сервиса за пределы локальной сети,
> 
> 3) используется традиционная для *NIX модель компонентности,
> основанная пошаговой декомпозиции задачи и использовании маленьких
> утилит и каналов. Иные модели остаются новацией, на успехи и
> последствия которой еще надо посмотреть.
Собственно, все это тот же PostScript-ориентированный подход, описываемый
(пока в очень осторожных и несколько размытых рамках) в этой дискуссии,
позволяет воплотить. Объемы документации на PS не обязательно диктуют,
что входной интерфейс библиотеки печати будет таким же распухшим.

> AB> Текст по кривым -- это не только DTP. Пусть не совсем точно по теме
> AB> дискуссии, но Вы ведь наверняка знакомы с проектом Berlin?
> Нет, не знаком, более того, полгода назад меня кто-то уже уличал в
> оном незнакомстве.
:-)

> AB> Отрисовка HTML в PostScript не покрывает всего спектра требований, хотя бы потому,
> AB> что некоторые элементы, необходимые сегодня (и имеющиеся, например, в расширения TeXа)
> AB> только обсуждаются в подкомитетах WWW.
> Предъявите весь спектр, пожалуйста. Серьезно.
SVG я уже описывал в начале письма. Собственно, давайте посмотрим, что
предлагается W3C в качестве языков описания разметки, если мы примем за
основу, что входным языком библиотеки печати должен быть некий
гипертекстовый механизм, который мы условно назовем HTML (в данном
контексте -- в приложении к "твердой" копии): 

1. xHTML как язык гипертекстового описания документа.
2. CSS3 как язык описания физических свойств элементов документа.
3. SVG как язык описания графических элементов.
4. MathML как язык описания математической символики.
5. ECMA Script как язык генерации элементов документа
   в процессе просмотра/печати.
Все?
CSS3 вводит нужные в нашем контексте разбиение на страницы и 
многоколоночность, ссылки на элементы на разных страницах
(см. стр. ХХХ), и другие вещи. CSS2 определяет довольно
полно модель прямоугольных фрагментов со сторонами, параллельными
осям координат в прямоугольной системе координат. Все операции
вращения полностью отсутствуют.

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

Что мы получаем: библиотека представляет собой, фактически,
отдельный встраиваемый браузер, который не позволяет печатать
документы с искаженными свойствами отдельных шрифтов/глифов/символов.
Тем самым, идея общей библиотеки печати теряется -- необходимо делать
дополнительный механизм для реализации отсутствующих возможностей
(которые, в свою очередь, не есть принадлежность конкретных
и немногочисленных программных средств).

> AB> А, главное, нет библиотеки корректного рендеринга HTML в
> AB> PostScript, как уже Алексей наглядно показал :-)
> Все же (как давно юзер, а не кодер) хочу фильтр, а не библиотеку ;)
Написать фильтр, имея библиотеку, в десятки раз проще, чем "гонять"
один и тот же код из одного проекта в другой, пристраивая его
каждый раз в общую инфраструктуру. Нагляднейшие примеры: фильтр
вордовских документов, переросший в библиотеку wvHTML и демонстрационная
реализация парсера XML, ставшая библиотекой Expat этим летом.

-- 
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
-- Better late than never.
		-- Titus Livius (Livy)