[docs] Re: mdash and nbsp (was: docs)

[Vitaly Ostanin]

On Tue, 19 Nov 2002 16:54:06 +0300
"Anton V. Boyarshinov" <boyarsh на ru.echo.fr> wrote:

> On Tue, 19 Nov 2002 16:43:04 +0300
> > > > Массовая расстановка &nbsp; - это не мелкая правка :)
> [skip]
> 
> > > > По-хорошему, это надо делать стилями.
> > > 
> > > Я не уверен в том, что это будет по хорошему. 
> > > Работу скрипта можно проконтролировать и откатить лишние
> > > изменения.
> > > Встроиться в обработку всех текстовых узлов и ничего при
> > > этом не поломать на xslt не так-то просто и должно ощутимо
> > > замедлить процес накладывания стилей.
> > 
> > То есть вопросов два:
> > 
> > 1. 
> > Обрабатывать &mdash; каждый раз перед сборкой результирующего
> > формата, или обрабатывать &mdash; один раз и хранить
> > изменения в документе.
> > 
> > Первый вариант более "автоматический", хоть и затратный по
> > времени. Во втором варианте документ может быть изменён на
> > предмет &mdash; уже после разовой обработки скриптом.
> 
> Обработать ещё раз перед публикацией. Зато есть контроль.

Тогда зачем обрабатывать "по запросу" и изменять исходные
документы?

> > 2. 
> > Написать скрипт на xslt или на perl.
> > 
> > Я бы предпочёл на xslt, как заточенный на работу с XML. Не
> > уверен, что на perl будет просто учитывать, например,
> > &mdash;, представленный символом из cp1251.
> 
> perl не будет. Но я его научу ;) Вариантов представления тире
> не тка уж и много.
> XSLT заточен на работу с XML, но в терминах узлов. На работу с
> текстовыми узлами он не заточен

На xslt проверку mdash сделать можно, и не так уж сложно. Скажем,
я берусь, но не обещаю быстро.

> > К тому же у меня есть
> > предварительный вариант такого стиля на xslt. 
> 
> Для стиля, который делает разовое преобразования или который
> встраивается в Уолшевские стили? Если первое -- я не вижу
> смысла трудно писать на XSLT то, что займёт 1 строку не perl.

Мне крайне не нравится идея использовать perl для сборки или
работы с XML-документами. 

Уже есть XML и XSLT - зачем приплетать ещё и громоздкий
нечитаемый perl ? Не говоря уже о проблемах совместимости и
пересборки версий (см. недавнее обсуждение в devel@)... Нам этого
добра и с libxml2/passivetex хватит.

> > Кстати, какого рода могут быть поломки при обработке
> > текстовых узлов с xslt ?
> 
> Имеется в виду -- если встраиваться в стили.

При релизной сборке вряд ли удастся уложиться в один проход
стилями. Кроме mdash нужно будет делать и другие проверки - дефис
вместо тире, точки с запятой в конце перечислений, пробел перед
точкой и т.п.

Так что можно не встраиваться в стили, а написать свой
со всеми этими проверками, тем более, что в обновляемые стили
Уолша так просто не встроишься.

> > > > Я знаю про время и про реальность, но делать криво ради
> > > > скорости подготовки док мне кажется неправильным. "Криво"
> > > > - это в самом общем смысле, &nbsp; в данном случае не так
> > > > уж криво.
> > > 
> > > Мне кажется, что расстановка &nbsp; непосредственно в
> > > документах-- не криво.
> > 
> > Для авторов и сборщиков, IMHO, такую расстановку удобнее
> > сделать стилем. В любом случае, её придётся проверять.
> 
> Отдельным стилем? Без разницы, более того, как на XSLT писать в
> исходный файл (пожалуй, это возможно, но я бы не стал)?

Да, отдельным стилем, и писать в исходный файл, IMHO не нужно -
стили можно научить создавать отчёт о проблемных местах в
документе, поскольку лучше вносить изменения в исходный документ
вручную.

Кстати, для изменения исходного файла можно обработанный вывод
переименовать в исходное имя файла.

Ааааа... Не надо перла... :)

> Встраивать? Тогда теряем контроль над происходящим, так как
> после преобразования в html или fo махать кулаками уже поздно.

Нет, не встраивать, а делать промежуточную обработку в конечный
XML-файл, а потом уже в html/fo.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt на vzljot.ru
JID:     vyt на vzljot.ru
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : /pipermail/docs/attachments/20021119/124351b4/attachment.bin