From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Maksim Otstavnov X-Mailer: The Bat! (v1.46d) Educational Organization: home office X-Priority: 3 (Normal) Message-ID: <1788910075.20010103182046@otstavnov.com> To: Aleksey Novodvorsky , Alexander Bokovoy In-reply-To: <3A526DC7.B7B30C05@logic.ru> References: <3A4DD97D.1FDC1C87@logic.ru> <192050037.20001230162110@otstavnov.com> <3A4E15F2.46239E7D@logic.ru> <15213114625.20001230192534@otstavnov.com> <3A4E3A5E.20111343@logic.ru> <3221979759.20001230215317@otstavnov.com> <3A4ED13D.B14EEAFF@logic.ru> <1935007249.20001231132322@otstavnov.com> <20001231155655.B11084@avilink.net> <19521357102.20001231175550@otstavnov.com> <20010101113653.A1406@avilink.net> <1683384193.20010101225905@otstavnov.com> <3A5107EC.8448D2C9@logic.ru> <5070584627.20010102173905@otstavnov.com> <3A524D20.EA1CCD01@logic.ru> <1085880728.20010103010659@otstavnov.com> <3A526DC7.B7B30C05@logic.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Subject: [mdk-re] =?koi8-r?B?cHJpbnQgbGliIGlzc3VlIChXYXM6IFJlWzJdOiBbbWRrLXJlXSAuLi7vINDP?= =?koi8-r?B?3tTFIMnULtAuKQ==?= Sender: mandrake-russian-admin@linuxteam.iplabs.ru Errors-To: mandrake-russian-admin@linuxteam.iplabs.ru X-BeenThere: mandrake-russian@linuxteam.iplabs.ru X-Mailman-Version: 2.0 Precedence: bulk Reply-To: mandrake-russian@linuxteam.iplabs.ru X-Reply-To: Maksim Otstavnov List-Help: List-Post: List-Subscribe: , List-Id: Mandrake/RE discussion list List-Unsubscribe: , List-Archive: Date: Wed Jan 3 18:53:11 2001 X-Original-Date: Wed, 3 Jan 2001 18:20:46 +0300 Archived-At: List-Archive: 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 писать _все равно придется_. 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