[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:
>
>
> > > > Первый вариант более "автоматический", хоть и затратный
> > > > по времени. Во втором варианте документ может быть
> > > > изменён на предмет — уже после разовой обработки
> > > > скриптом.
> > >
> > > Обработать ещё раз перед публикацией. Зато есть контроль.
> >
> > Тогда зачем обрабатывать "по запросу" и изменять исходные
> > документы?
>
> Что бы более-менее постоянно поддерживать их в нормальном
> состоянии.
> Чем меньше нестандартной post обработки мы вносим -- тем лучше.
Не спорю.
Вариант обработки документов, создания отчёта о возможно
проблемных местах, годится? Или нужно в пакетном режиме менять
исходник? В принципе, это можно сделать опционально.
> > > > 2.
> > > > Написать скрипт на xslt или на perl.
> > > >
> > > > Я бы предпочёл на xslt, как заточенный на работу с XML.
> > > > Не уверен, что на perl будет просто учитывать, например,
> > > > —, представленный символом из 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.
> > > > > > Я знаю про время и про реальность, но делать криво
> > > > > > ради скорости подготовки док мне кажется
> > > > > > неправильным."Криво"- это в самом общем смысле,
> > > > > > в данном случае не так уж криво.
> > > > >
> > > > > Мне кажется, что расстановка непосредственно в
> > > > > документах-- не криво.
> > > >
> > > > Для авторов и сборщиков, 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