[mdk-re] print lib issue (Was: Re[2]: [mdk-re] ...О почте ит.п.)

[Maksim Otstavnov]

Hello,

я из этого обсуждения вынес:

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

"Библиотека печати" мне по-прежнему кажется исключительно неудачным
примером. Поскольку непонятно, что туда должно входить и непонятны
критерии готовности, зато понятно, что обсуждение ТЗ и этих критериев
- это и есть 2/3 всей работы. Т.е. речь идет скорее об
исследовательском проекте в весьма расплывчатых рамках.

Фильтр из формата А в формат Б гораздо более выгодно смотрится в этом
отношении, поскольку спецификации форматов почти исчерпывающе его
специфицируют, критерии готовности очевидны и с большой вероятностью
можно найти готовые тесты.

По "материи" собственно кодирования большой разницы я не вижу: что
фильтр разобрать на функции, что из функций собрать фильтр -
техническая и не слишком объемная работа.

2. Отдельное спасибо за указание кучи контрпримеров к использованию
*ml и сопутствующих форматов в качестве промежуточных от "приложений"
к подсистеме печати.

Я согласен, что *ml покрывают не 90%, как я предполагал, а, допустим,
75% ситуаций :) И я согласен, что среди оставшихся - много важных и
нужных.

Вполне возможно, что использование *ml действительно было бы большой
прагматической ошибкой, особенно ввиду сырости на сегодня SVG.

3. Но самое важное, что, обдумав все это, я совершенно закостенел в
убеждении (за что вам благодарен), что, несмотря на все вышесказанное,
библиотеки и тулкиты как таковые must die.

Точнее, идеология reusability/компонентности, основанная на построении
таковых.

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

И идеология "приложений" тоже мастдай. А вот изначальная модель
компонентности, напротив, rulez.

На сегодня я могу очень долго это аргументировать. Возможно, я отпишу
аргументы в отдельный текст.

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

Вообще, пример с библиотекой печати кажется сложным из-за множества
привходящих обстоятельств. Возможно, стоит поиграть с
библиотеками/языками GUI в той же логике: набросать, например, как бы
мог выглядеть язык графического диалога, основанного, например, на
GTK+.

Собственно, Вагнер это предлагал некоторое время назад, и даже что-то
начал делать, но, кажется, бросил или, по крайней мере, отложил.

5. Далее огрызаюсь по мелочам.

Wednesday, January 03, 2001, 3:09:43 AM, you wrote:

(НАТО)

>> Они до сих пор и следуют. Для части закупаемого и разрабатываемого
>> Пентагоном софта требования "поддержки кириллических языков" уже
>> является обязательным. Это трактуется (-овалось?) как следование
>> ISO...5, а потом им пришлось ставить рекодирующие прокси, чтобы читать
>> русский Web.

AN> Страное решение.

Так и можно надеяться, что они уже нахлебались. Но у них реальная
проблема с тем, что ведомственные спецификации заимствуют контекст
GOSIP, а там четко написано, что утвержденные стандарты ISO
перекрывают все (в отличие от ГП ВОС, отдающего приоритет нац.
стандартам над международными). И зреет бунт.

>> Да, конечно. Я ж не жалуюсь. На НАТО кивал только как на потенциальный
>> источник дешевых ресурсов.

AN> Зная немного о проектах, которые они финансируют, боюсь, что
AN> деньги они кидают на ветер, причем дующий явно не в ту сторону.

Я видел один раз, как принималось решение по контракту (правда, не в
ИТ-области, а на поставку услуг), и остался весьма впечатлен.


(Иврит/идиш/нац. культура/гос. строительство/религия)

>> Для Бен-Иегуды и компании этот мотив (единство священного и
>> литературного языка) был основным, если верить ему самому.

AN> Конечно. Но этот "мотив" может проистекать вовсе не из ортодоксии.
AN> Не забыайте, что доля религиозников не была слишком значительна
AN> среди тех, кто принял этот язык.

На самом деле, по большому счету правы Вы: в раннем сионизме были
разные течения.

Однако, немаловажно, что Бен-Иегуда создавал, фактически, язык
_светского общения_ на основе _живой_ традиции использования
еврейского не только в ритуале, но и в комментировании. Т.е. за
пределами Европы раввины _говорили_ на этом языке, хотя только на
религиозные темы. И если бы не было этой практики, вряд ли из иврита
что-то получилось бы.

AN> Да, но отказ от идиш имел вполне определенные причины в
AN> сложившейся обстановке, далекие от религиозных.

Так ли уж далекие?

(I18n/печать)

>> AN> На самом деле положение дел с i18n в OSS становится лучше очень
>> AN> быстро. Я бы даже сказал -- значительно быстрее, чем в самых моих
>> AN> оптимистических прогнозах. И слушают нас уже очень неплохо. Но мы
>> AN> могли бы внести еще больший вклад в это общее дело.
>>
>> Может быть, драфт главы i18n про печать был бы бОльшим вкладом, чем
>> гипотетическая библиотека печати?

AN> Не бОльшим, но большИм. Другое дело, что для полноправного участия
AN> в уже закрывшихся, в общем-то, комитетах, нужны некоторые
AN> средства.

I18N сейчас ведь под эгидой li.org? Там не должно быть излишней
забюрократизованности и т.п., и в любом случае, начинать нужно с
problem statements, FAQs и RFCs.

Wednesday, January 03, 2001, 2:42:12 AM, Alexander wrote:

(*ml/печать)

>> Использовать то, что есть. Сегодня HTML хватит для 90% приложений. А
>> html2ps писать _все равно <sigh> придется_.
AB> Безусловно. Только вот тем приложениям, которые рисуют (а это не только
AB> пресловутые растровые и векторные редакторы, а разнообразные научные
AB> программы в том числе), возможностей HTML будет маловато.

Да, да. Я уже вижу.

>> 3) используется традиционная для *NIX модель компонентности,
>> основанная пошаговой декомпозиции задачи и использовании маленьких
>> утилит и каналов. Иные модели остаются новацией, на успехи и
>> последствия которой еще надо посмотреть.
AB> Собственно, все это тот же PostScript-ориентированный подход, описываемый
AB> (пока в очень осторожных и несколько размытых рамках) в этой дискуссии,
AB> позволяет воплотить.

Дилемма в том, вводить ли дополнительный уровень абстракции (речь об
этом?) как препроцессинг/фильтрацию/whatever или писать тулкит.

AB> Объемы документации на PS не обязательно диктуют, что входной
AB> интерфейс библиотеки печати будет таким же распухшим.

Не диктуют. Просто интерфейсы имеют обыкновение распухать
самопроизвольно, если нет ограничений by design.

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

А чего смеяться? Пальцем покажите.

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

AB> 1. xHTML как язык гипертекстового описания документа.
AB> 2. CSS3 как язык описания физических свойств элементов документа.
AB> 3. SVG как язык описания графических элементов.
AB> 4. MathML как язык описания математической символики.
AB> 5. ECMA Script как язык генерации элементов документа
AB>    в процессе просмотра/печати.
AB> Все?

6. Пачку растрово-графических форматов, пока это не поглощено SVG.

AB> CSS3 вводит нужные в нашем контексте разбиение на страницы и 
AB> многоколоночность, ссылки на элементы на разных страницах
AB> (см. стр. ХХХ), и другие вещи. CSS2 определяет довольно
AB> полно модель прямоугольных фрагментов со сторонами, параллельными
AB> осям координат в прямоугольной системе координат. Все операции
AB> вращения полностью отсутствуют.

Это да. И SVG сырая.

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

Да слава богу, что не ставит, иначе вообще бы ничего не сделали.

Но слова "идеально подходящих" меня несколько пугают. Я сильно
предпочитаю (как юзер) вещи, которые just work.

AB> Что мы получаем: библиотека представляет собой, фактически,
AB> отдельный встраиваемый браузер, который не позволяет печатать
AB> документы с искаженными свойствами отдельных шрифтов/глифов/символов.

Только рендер, а не целый браузер. Навигации нам не надо ;)


-- 
-- M