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

Vitaly Ostanin vyt на vzljot.ru
Вт Ноя 19 18:20:00 MSK 2002


On Tue, 19 Nov 2002 17:47:18 +0300
"Anton V. Boyarshinov" <boyarsh на ru.echo.fr> wrote:

> On Tue, 19 Nov 2002 17:28:15 +0300
> Vitaly Ostanin <vyt на vzljot.ru> wrote:
> 
> 
> > > > Первый вариант более "автоматический", хоть и затратный
> > > > по времени. Во втором варианте документ может быть
> > > > изменён на предмет &mdash; уже после разовой обработки
> > > > скриптом.
> > > 
> > > Обработать ещё раз перед публикацией. Зато есть контроль.
> > 
> > Тогда зачем обрабатывать "по запросу" и изменять исходные
> > документы?
> 
> Что бы более-менее постоянно поддерживать их в нормальном
> состоянии. 
> Чем меньше нестандартной post обработки мы вносим -- тем лучше.

Не спорю.

Вариант обработки документов, создания отчёта о возможно
проблемных местах, годится? Или нужно в пакетном режиме менять
исходник? В принципе, это можно сделать опционально.

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

Эта программа будет понимать объявления кодировки, включения
xinclude, элементы CDATA, Вы берётесь её поддерживать ? Тогда я
только за, даже на perl.

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

:)
Привнося в проект новую компоненту или язык, мы его усложняем.

> Не надо навешивать ярлыков. Если тут кто и нечитаемый, то TeX
> (passivetex на нём написан) и XSL-FO. Если очень не нравится
> perl, мысленно заменяйте слово perl на слово sed.

И TeX нечитаемый :) Без XSL-FO мы обойтись не можем, а вот без
perl...

> > Не говоря уже о проблемах совместимости и
> > пересборки версий (см. недавнее обсуждение в devel@)... Нам
> > этого добра и с libxml2/passivetex хватит.
> 
> Нет проблем совместимости для скрипта из одного оператора. Нет
> их.

<jt>
Отсутствие проблем - временное явление :)
</jt>

> > > > Кстати, какого рода могут быть поломки при обработке
> > > > текстовых узлов с xslt ?
> > > 
> > > Имеется в виду -- если встраиваться в стили.
> > 
> > При релизной сборке вряд ли удастся уложиться в один проход
> > стилями.
> 
> А приходится. Потому, что собственный docbook->fo не написать,
> а Уолшевские требуют именно docbook на входе.

Я не предлагаю менять docbook не в docbook.

> > Кроме mdash нужно будет делать и другие проверки - дефис
> > вместо тире, точки с запятой в конце перечислений, пробел
> > перед точкой и т.п.
> 
> Это всё в рамках unix way решается элементарно.

У нас используются ещё и возможности XML :)

> Для контроля -- grep
> Для исправления perl (sed)

Из перечисленных лучше всего работает с XML именно xslt.

> > Так что можно не встраиваться в стили, а написать свой
> > со всеми этими проверками, тем более, что в обновляемые стили
> > Уолша так просто не встроишься.
> 
> Полностью свой стиль? Сколько лет ушло у того аспиранто на
> построение правильного многоуголника с (не помню, но число было
> пятизначное) сторонами?

Полностью свой стиль с несколькими шаблонами.

> Встроиться в стили Уолша проще, чем кажется. Я альтерантивным
> стилем заниматься не буду. Я достаточно покопался в недрах
> Уолшевских стилей, что бы представить: сколько труда туда
> вложено.

Я недостаточно покопался, но тоже представляю :) Я не говорю об
альтернативном. Я говорю о стиле, который будет проверять
документы на соответствие требованиям ALT DOCS и либо изменять их
для соответсвия этим требованиям, либо создавать отчёт с
bugreports.

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

Ну мы же все доки хотим качественными :)

> > Ааааа... Не надо перла... :)
> 
> Фобия? ;)

<jt>
Да :)) Над своими же скриптами на perl приходится сидеть,
вспоминая, что ж я тогда имел в виду...
</jt>

> > > Встраивать? Тогда теряем контроль над происходящим, так как
> > > после преобразования в html или fo махать кулаками уже
> > > поздно.
> > 
> > Нет, не встраивать, а делать промежуточную обработку в
> > конечный XML-файл, а потом уже в html/fo.
> 
> И если надо что-то подправить (произошла замена там где не
> надо)-- делать это КАЖДЫЙ раз с промежуточным файлом.

Почему с промежуточным?

Чтобы сделать обсуждение более конструктивным, повторю вопросы:

1.
На чём писать проверочную обработку документов - perl или xslt.

Обработка должна уметь автоматом вносить изменения или делать
отчёт об их возможности.

Я по-прежнему perl'ом не убеждён, буду благодарен за
дополнительные мнения.

2.
Хранить ли изменения в исходных документах, или вносить их перед
сборкой в промежуточный docbook/xml с последующим скармливанием
оригинальным стилям.

Сейчас я думаю, что единственное изменение, которое не стоит (не
обязательно) хранить в документах - это nbsp перед mdash, а
остальные правки (; в конце перечислений) должны заноситься в
исходник. В общем, теперь я за хранение изменений в исходниках.

<skipped/>

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


Подробная информация о списке рассылки docs