[docs] возможности улучшения db2latex

[Kirill Maslinsky]

Всем привет!

В выводе db2latex присутствуют некоторые регулярные ошибки 
(или, скажем мягче, недальновидные решения разработчиков), 
исправив которые можно сделать немного более реальной 
качественную автоматическую обработку документации через 
LaTeX да и вообще всю автоматическую обработку документации. 
Во всяком случае, мне так кажется ;)

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

Проблемы локализации типографских правил.

Тире: 

Крайне желательно использовать \cyrdash, определенный в babel а не 
английский \emdash, поскольку так сразу рещается проблема с тире, которое
не должно начинать строку и выполнятся русская типографская норма длины
текстового тире. 


Кавычки: 
неплохо бы использовать свой макрос, который будет ставить нужные 
кавычки, смотря по глубине вложения (елочки или лапки), и проверять,  
Возможны ли в DocBook вообще вложенные кавычки, и если да, то да какого 
уровня? В реальности стоит ограничивать этот уровень 2-мя 
(в крайнем случае -- 3-мя). 
Макрос на Латехе могу написать сам. 

Следить за тем, чтобы не было пробелов после кавычек и перед ними -- 
это можно вписать в сам формат DocBook? 

При экспорте в Латех кавычки должны закрываться пустыми скобками, чтобы не 
слипались со следующим словом. Вообще так следует поступать со всеми 
командами без аргументов.

Entities раскрываются в конечные команды форматирования Латеха, в то время
как логично сохранить entities в Латехе, а конкретные указания по 
форматированию вынести в стилевой пакет. 

Например: 

&LINUX; -> {\texttt{{Linux}}} 

(Кстати, почему-то определяется локально в данном .xml-файле, а не глобально)
<!ENTITY LINUX "<systemitem class='osname'>Linux</systemitem>">


А хотелось бы: 

&LINUX; -> \osname{Linux} 

local.sty
\newcommand{\osname}[1]{\mbox{\texttt{#1}}}
(мы ведь еще не хотим, чтобы оно переносилось, верно? 
правда, это может оказаться слишком жестким требованием, возможно, 
нужно просто указать ТеХу, что здесь переносы невозможны, а разрывы 
строки на пробелах нежелательны.)

Или даже: 

&LINUX; -> \Linux{}

local.sty 
аналогично предыдущему примеру

entities.sty
Специальный промежуточный файл, в котором будет определено, как 
макросы, соответствующие docbook'овским entities, будут раскрываться
в строки.

\newcommand{\Linux}{\osname{Линукс}}

Идеально, чтобы "заготовки" для этих двух .sty файлов db2latex порождал 
сам в качестве вывода, а пользователь затем мог исправить как оформление 
логических элементов структуры, так и процесс раскрытия макросов в конечные
строки. По необходимости, здесь можно добавить ТеХовское форматирование. 
Для чего может понадобиться именно ТеХовское форматирование: 

В документации все время встречаются "и т. д." и "и т. п.", которые пишутся 
то с пробелом, то без, "т. д." может уйти на другую строку... Сразу 
характеризует текст как неаккуратный. Предлагается: завести в docbook entity, 
что-нибудь вроде 

&ITD; -> \itd{}

entities.sty

\newcommand{\itd}{и~т.\,д.}

Возможно ли в DocBook указать, что некоторые пробелы должны быть 
неразрывными? А что некоторые должны быть тонкими? (шириной .3 ширины 
прописной буквы М текущего шрифта, если быть точным ;)) 
По крайней мере для тех форматов, которые подразумевают печать на 
бумаге.

По содержанию: 

Обрабатывает ли как-нибудь db2latex сведения об авторе _раздела_? 
Потому что хотелось бы в общем случае указать для каждого раздела 
автора. (Хотя уже видел дискуссию об авторах в архивах рассылки...)

Зачем в некоторых списках использован glosslist?
см. например /docs/books/junior-2.3/intro/support/support.xml

Разве от бедности возможностей разметки docbook? Это же не список 
терминов, там и заголовки не в одно-два слова, следовательно, 
используемое в TeXe для оформления такого списка окружение 
description выглядит ужасно, поскольку рассчитано на короткие метки. 
Наверное, в docbook есть для таких случаев другой тип списка? 
Хотя на мой взгляд это уже больше похоже на подзаголовок.
Вообще желательно в ТеХе использовать не стандартный 
description, а что-нибудь вроде glosslist, определяя его все в том же 
гипотетическом local.sty.

Как реализовать специфические дефисы в сложных словах: неразрывный дефис, 
в словах типа OEM-партнеры, а также дефис, позволяющий переносить части 
сложного слова (второе, скорее всего, специфично для ТеХа)?

Продолжение следует...

В общем, кого что заинтересовало -- спрашивайте, я каждому отвечу, 
каждый пункт можно обсудить, оценить и, если понравится, конечно же, -- 
реализовать самому! ;)

КМ