Учебник по Проекту Документирования FreeBSD для новых участников

The FreeBSD Documentation Project

Благодарим вас за то, что вы стали частью Проекта Документирования FreeBSD. Ваше участие чрезвычайно нужно.

Этот учебник описывает все, что вам нужно знать для того, чтобы принять участие в Проекте Документирования FreeBSD, от инструментов и программного обеспечения, которое вы будете использовать (как обязательное, так и рекомендуемое), до философии Проекта Документирования.

Этот документ все время подвергается изменениям, и не полон. Еще не законченные разделы помечены знаком * в названии.

Распространение и использование исходных (SGML DocBook) и ''скомпилированных'' форм (SGML, HTML, PDF, PostScript, RTF и прочих) с модификацией или без оной, разрешены при соблюдении следующих соглашений:

  1. Распространяемые копии исходного кода (SGML DocBook) должны сохранять вышеупомянутые объявления copyright, этот список положений и следующий отказ от ответственности в первых строках этого файла в неизменном виде.

  2. Распространяемые копии скомпилированных форм (преобразованные в другие DTD, конвертированные в PDF, PostScript, RTF и другие форматы) должны повторять вышеупомянутые объявления copyright, этот список положений и следующий отказ от ответственности в документации и/или других материалах, поставляемых с дистрибьюцией.

Важно: ЭТА ДОКУМЕНТАЦИЯ ПОСТАВЛЯЕТСЯ ПРОЕКТОМ ДОКУМЕНТАЦИИ FREEBSD "КАК ЕСТЬ" И ЛЮБЫЕ ЯВНЫЕ ИЛИ НЕЯВНЫЕ ГАРАНТИИ, ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ НЕЯВНЫМИ ГАРАНТИЯМИ, КОММЕРЧЕСКОЙ ЦЕННОСТИ И ПРИГОДНОСТИ ДЛЯ КОНКРЕТНОЙ ЦЕЛИ ОТРИЦАЮТСЯ. НИ ПРИ КАКИХ УСЛОВИЯХ ПРОЕКТ ДОКУМЕНТИРОВАНИЯ FREEBSD НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБОЙ ПРЯМОЙ, КОСВЕННЫЙ, СЛУЧАЙНЫЙ, СПЕЦИАЛЬНЫЙ, ОБРАЗЦОВЫЙ ИЛИ ПОСЛЕДУЮЩИЙ УЩЕРБЫ (ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯСЬ ПОСТАВКОЙ ТОВАРОВ ЗАМЕНЫ ИЛИ УСЛУГ; ПОТЕРЮ ДАННЫХ ИЛИ ИХ НЕПРАВИЛЬНУЮ ПЕРЕДАЧУ ИЛИ ПОТЕРИ; ПРИОСТАНОВЛЕНИЕ БИЗНЕСА), И ТЕМ НЕ МЕНЕЕ ВЫЗВАННЫЕ И В ЛЮБОЙ ТЕОРИИ ОТВЕТСТВЕННОСТИ, НЕЗАВИСИМО ОТ КОНТРАКТНОЙ, СТРОГОЙ ОТВЕТСТВЕННОСТИ, ИЛИ ПРАВОНАРУШЕНИИ (ВКЛЮЧАЯ ХАЛАТНОСТЬ ИЛИ ИНЫМ СПОСОБОМ), ВОЗНИКШЕМ ЛЮБЫМ ПУТЕМ ПРИ ИСПОЛЬЗОВАНИИ ЭТОЙ ДОКУМЕНТАЦИИ, ДАЖЕ ЕСЛИ БЫ БЫЛО СООБЩЕНО О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА.


Содержание
Используемые сокращения
Приглашения командных процессоров
Типографские соглашения
Замечания, советы, важная информация, предупреждения и примеры
Благодарности
1. Обзор
1.1. Набор документации FreeBSD
1.2. До того, как вы начнете
1.3. Быстрое начало
2. Инструменты
2.1. Обязательные инструменты
2.1.1. Программное обеспечение
2.1.2. DTD и сущности
2.1.3. Таблицы стилей
2.2. Необязательные инструменты
2.2.1. Программное обеспечение
3. Учебник SGML
3.1. Обзор
3.2. Элементы, метки и атрибуты
3.2.1. Упражнения...
3.3. Декларация DOCTYPE
3.3.1. Идентификаторы FPI
3.3.2. Альтернативы FPI
3.4. Возвращение к SGML
3.5. Комментарии
3.5.1. Упражнения...
3.6. Сущности
3.6.1. Сущности общего вида
3.6.2. Параметризированные сущности
3.6.3. Упражнения...
3.7. Использование сущностей для включения файлов
3.7.1. Использование сущностей общего назначения для включения файлов
3.7.2. Использование параметризированных сущностей для включения файлов
3.7.3. Упражнения...
3.8. Отмеченные разделы
3.8.1. Ключевые слова помеченного раздела
3.8.2. Упражнения...
3.9. Заключение
4. Разметка SGML
4.1. HTML
4.1.1. Формальный Публичный Идентификатор (Formal Public Identifier - FPI)
4.1.2. Элементы разделов
4.1.3. Блочные элементы
4.1.4. Строчные элементы
4.1.5. Ссылки
4.2. DocBook
4.2.1. Расширения FreeBSD
4.2.2. Формальный Публичный Идентификатор (Formal Public Identifier - FPI)
4.2.3. Структура документа
4.2.4. Блочные элементы
4.2.5. Строчные элементы
4.2.6. Изображения
4.2.7. Ссылки
5. * Таблицы стилей
5.1. * DSSSL
5.2. CSS
5.2.1. Веб-сайт (документы HTML)
5.2.2. Документы DocBook
6. Структурирование документов в doc/
6.1. Самый верхний уровень, doc/
6.2. Каталоги lang.encoding/
6.3. Информация, специфичная для конкретных документов
6.3.1. Руководство
7. Процесс построения документации
7.1. Набор инструментов для построения документации FreeBSD
7.2. Понимание make-файлов в дереве документации
7.2.1. Make-файлы в подкаталоге
7.2.2. Make-файлы для документации
7.3. Включаемые make-файлы Проекта Документирования FreeBSD
7.3.1. doc.project.mk
7.3.2. doc.subdir.mk
8. Web-сервер
8.1. Подготовка
8.2. Построение Web-страниц с нуля
8.3. Установка Web-страниц в ваш Web-сервер
8.4. Переменные окружения
9. Переводы
10. Стиль написания
10.1. Руководство по стилю
10.1.1. Регистр букв
10.1.2. Акронимы
10.1.3. Отступы
10.1.4. Стиль меток
10.1.5. Изменения, затрагивающие только количество пробелов
10.1.6. Непрерываемые пробелы
10.2. Словарь
11. Использование Emacs в режиме sgml-mode
12. Дополнительные источники информации
12.1. Проект Документирования FreeBSD
12.2. SGML
12.3. HTML
12.4. DocBook
12.5. Проект Документирования Linux
A. Примеры
A.1. DocBook <book>
A.2. DocBook <article>
A.3. Получение форматированного вывода
A.3.1. Использование Jade
Список примеров
1. Пример
3-1. Использование элемента (начальная и конечная метки)
3-2. Использование элемента (только начальная метка)
3-3. Элементы внутри элементов; <em>
3-4. Использование элемента с атрибутом
3-5. Атрибуты в одинарных кавычках
3-6. .profile для пользователей sh(1) и bash(1)
3-7. .cshrc, для пользователей csh(1) и tcsh(1)
3-8. Комментарий SGML общего вида
3-9. Комментарии SGML с ошибкой
3-10. Задание сущностей общего назначения
3-11. Задание параметризированных сущностей
3-12. Использование сущностей общего назначения для включения файлов
3-13. Использование параметризированных сущностей для включения файлов
3-14. Структура отмеченного раздела
3-15. Использование разделов, помеченных как CDATA
3-16. Использование INCLUDE и IGNORE в помеченных разделах
3-17. Использование параметризованной сущности для управления помеченным разделом
4-1. Обычная структура документа HTML
4-2. <h1>, <h2> и так далее.
4-3. Неправильный порядок следования элементов <hn>
4-4. <p>
4-5. <blockquote>
4-6. <ul> и <ol>
4-7. Списки определений с <dl>
4-8. <pre>
4-9. Простое использование <table>
4-10. Использование rowspan
4-11. Использование colspan
4-12. Использование rowspan и colspan одновременно
4-13. <em> и <strong>
4-14. <b> и <i>
4-15. <tt>
4-16. <big>, <small> и <font>
4-17. Использование <a href="...">
4-18. Использование <a name="...">
4-19. Ссылка на именованную часть другого документа
4-20. Ссылка на именованную часть того же самого документа
4-21. Заготовка для <book> с <bookinfo>
4-22. Заготовка <article> с <articleinfo>
4-23. Простая глава
4-24. Пустые главы
4-25. Разделы в главах
4-26. <para>
4-27. <blockquote>
4-28. <warning>
4-29. <itemizedlist>, <orderedlist> и <procedure>
4-30. <programlisting>
4-31. <co> и <calloutlist>
4-32. <informaltable>
4-33. Таблицы с frame="none"
4-34. <screen>, <prompt> и <userinput>
4-35. <emphasis>
4-36. Цитирование
4-37. Клавиши, кнопки мыши и комбинации
4-38. Приложения, команды и параметры.
4-39. <filename>
4-40. <filename> с атрибутом role
4-41. <devicename>
4-42. <hostid> и роли
4-43. <username>
4-44. <maketarget> и <makevar>
4-45. <literal>
4-46. <replaceable>
4-47. <errorname>
4-48. id в главах и разделах
4-49. <anchor>
4-50. Использование <xref>
4-51. Использование <link>
4-52. <ulink>
A-1. DocBook <book>
A-2. DocBook <article>
A-3. Преобразование DocBook в HTML (один большой файл)
A-4. Преобразование DocBook в HTML (несколько маленьких файлов)
A-5. Преобразование DocBook в Postscript
A-6. Преобразование DocBook в PDF

Используемые сокращения

Приглашения командных процессоров

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

Пользователь Приглашение
Обычный пользователь %
root #

Типографские соглашения

В следующей таблице описаны типографские соглашения, используемые в этой книге.

Значение Примеры
Названия команд, имена файлов и каталогов. Выдача на экран.

Отредактируйте ваш файл .login.

Используйте команду ls -a для выдачи списка всех файлов.

You have mail.


То, что набираете вы, когда это отличается от экранной выдачи компьютером.
% su
Password:
Ссылки на страницы справочной системы. Воспользуйтесь командой su(1) для смены имени пользователя.
Имена пользователей и групп Только root может это делать.
Выделение Вы должны это сделать.
Переменные параметры командной строки; заменяйте их реальными названиями или значениями. Для удаления файла наберите rm filename
Переменные окружения $HOME является вашим домашним каталогом.

Замечания, советы, важная информация, предупреждения и примеры

Внутри текста встречаются замечания, предупреждения и примеры.

Замечание: Замечания имеют такой вид, и содержат информацию, которую вы должны принять к сведению, так как она может затронуть ваши действия.

Подсказка: Советы имеют такой вид, и содержат информацию, которая может оказаться полезной для вас, или предлагают более простой способ сделать что-либо.

Важно: Важная информация имеет такой вид. Обычно здесь обращается внимание на дополнительные действия, которые вам может потребоваться выполнить.

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

Пример 1. Пример

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


Благодарности

Я благодарю Sue Blake, Patrick Durusau, Jon Hamilton, Peter Flynn и Christopher Maden, которые выбрали время для чтения ранних черновиков этого документа и дали много ценных замечаний и критики.


Глава 1. Обзор

Добро пожаловать в Проект Документирования FreeBSD. Наличие документации хорошего качестве очень важно для успеха FreeBSD, и Проект Документирования FreeBSD (FreeBSD Documentation Project - FDP) организован для создания этой документации. Ваше участие очень важно.

Главное назначение этого документа заключается в четком описании того, как организован FDP, как создавать и присылать документацию для FDP и как эффективно использовать доступные вам инструменты при написании документации.

К участию в FDP приглашаются все. Нет никаких минимальных требований, предъявляемых к участникам, нет квот по объему документации, которую вам нужно написать за месяц. Все, что вам нужно - это подписка на список рассылки Список рассылки Проекта Документации FreeBSD.

После того, как вы прочтете этот документ, вы должны:


1.1. Набор документации FreeBSD

В FDP ведется документация FreeBSD четырех категорий.

Страницы справочной системы

Системные англоязычные справочные страницы созданы не в FDP, так как они являются частью системы. Однако FDP может (и делает) перефразировать части существующих справочных страниц для того, чтобы сделать их более понятными или с целью устранения неточностей.

Команды переводчиков отвечают за перевод системных справочных страниц на другие языки. Эти переводы поддерживаются в FDP.

FAQ

FAQ предназначен для разрешения вопросов (в форме кратких ответов на них), которые задаются или могут задаваться в различных списках рассылки и новостных конференциях, посвященных FreeBSD. Формат не разрешает длинных и подробных ответов.

Руководство

Руководство предназначено быть полным онлайновым ресурсом и справочником для пользователей FreeBSD.

Веб-сайт

Это главное представительство FreeBSD в сети Интернет, доступное по адресу http://www.FreeBSD.org/ и на многих зеркалах по всему миру. Посещение веб-сервер является первым знакомством с FreeBSD для многих людей.

Эти четыре категории документации все доступны в дереве CVS FreeBSD. Это означает, что протоколы изменений в этих файлах общедоступны, и кто угодно может воспользоваться программой типа CVSup или CTM для хранения собственной копии этой документации.

Кроме того, на других веб-сайтах, посвященных FreeBSD, имеется много учебников, написанных другими людьми. Некоторые из них также располагаются в хранилище CVS (если автор согласился с этим). В других случаях автор решил хранить свою документацию отдельно от главного хранилища FreeBSD. FDP старается давать ссылки на максимальное количество такой документации.


1.2. До того, как вы начнете

В этом документе предполагается, что вы уже знаете:

  • Как поддерживать в актуальном состоянии локальную копию документации FreeBSD, ведя локальную копию CVS-хранилища FreeBSD (используя CVS или CVSup либо CTM) или используя CVSup для сгрузки только копии в режиме checked-out.

  • Как сгружать и устанавливать новое программное обеспечение при помощи либо системы портов FreeBSD, либо программы pkg_add(1).


1.3. Быстрое начало

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

  1. установите мета-порт textproc/docproj.

    # cd /usr/ports/textproc/docproj
    # make JADETEX=no install
    
  2. Создайте локальную копию дерева doc FreeBSD. Для этого воспользуйтесь CVSup в режиме checkout либо создайте полную локальную копию хранилища CVS.

    Если у ас имеется локальное хранилище CVS, то, как минимум, вам потребуется извлечь каталоги doc/share и doc/en_US.ISO8859-1/share.

    % cvs checkout doc/share
    % cvs checkout doc/en_US.ISO8859-1/share
    

    Если у вас достаточный объем дискового пространства, то вы можете вообще все.

    % cvs checkout doc
    
  3. Если вы готовите изменение к существующей книге или статье, извлеките их при необходимости из хранилища. Если вы планируете создать новую книгу или статью, то используйте существующие в качестве образца.

    Например, если вы хотите создать новую статью о настройте VPN между FreeBSD и Windows 2000, вы можете сделать следующее.

    1. Извлеките каталог articles.

      % cvs checkout doc/en_US.ISO8859-1/articles
      
    2. Скопируйте существующую статью для использования в качестве шаблона. В нашем случае вы решили, что ваша новая статья располагается в каталоге vpn-w2k.

      % cd doc/en_US.ISO8859-1/articles
      % cp -R committers-guide vpn-w2k
      

    Если вы хотите отредактировать существующий документ, такой, как FAQ, который размещается в каталоге doc/en_US.ISO8859-1/books/faq, вы должны извлечь его из хранилища примерно следующим образом.

    % cvs checkout doc/en_US.ISO8859-1/books/faq
    
  4. Отредактируйте файлы .sgml при помощи вашего любимого редактора.

  5. Оттестируйте разметку при помощи цели lint. При этом будут быстро найдены все ошибки в документе без реального выполнения занимающего время преобразования.

    % make lint
    

    Как только вы готовы на самом деле построить документ, то можете задать какой-то формат или список форматов в переменной FORMATS. В настоящее время поддерживаются html, html-split, txt, ps, pdf, и rtf. Самый свежий список поддерживаемых форматов находится в начале файла doc/share/mk/doc.docbook.mk. Если вы используете более чем один формат в одной команде, не забудьте заключить список форматов в двойные кавычки.

    Например, для преобразования документа только в формат html, вы должны использовать:

    % make FORMATS=html
    

    Но когда вы хотите преобразовать документ в оба формата html и txt, вы можете использовать либо два отдельных вызова make(1):

    % make FORMATS=html
    % make FORMATS=txt
    

    либо это можно сделать одной командой:

    % make FORMATS="html txt"
    
  6. Пришлите ваши изменения при помощи программы send-pr(1).


Глава 2. Инструменты

В FDP используется несколько разных программных средств, помогающих в управлении документацией FreeBSD, преобразовании ее в различные выходные форматы, и так далее. Вам потребуется самим использовать эти инструменты, если вы будете работать с документацией FreeBSD.

Все эти инструменты доступны в виде Портов и Пакаджей FreeBSD, что очень сильно упрощает работу по их установке .

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

По возможности используйте порт textproc/docproj: Вы можете сэкономить себе много времени, если установите порт textproc/docproj. Это мета-порт, который сам по себе не содержит программ. Однако он зависит от корректной установки различных других портов. При установке порта должны сгрузиться и установиться все нужные вам пакаджи, перечисленные в этой главе.

Один из пакаджей, который вам может потребоваться, является пакетом макросов JadeTeX. В свою очередь, этот пакет макросов требует наличия установленного TeX. TeX является большим пакетом, и он вам потребуется, если только вы будет генерировать вывод в форматах Postscript или PDF.

Для экономии собственного времени и дискового пространства вы должны указать, хотите ли вы устанавливать JadeTeX (а значит, и TeX) при установке этого порта. Выполните:

# make JADETEX=yes install

или

# make JADETEX=no install

при необходимости. Альтернативным способом является установка textproc/docproj-jadetex или textproc/docproj-nojadetex. Эти вторичные порты только определяют переменную JADETEX за вас, и таким образом они будут устанавливать на вашу машину один и тот же пакет приложений. Заметьте, что вы можете генерировать только текстовую выдачу в форматах HTML или ASCII, пока не установите JadeTeX. Для работы с PostScript или PDF требуется установка пакета TeX.


2.1. Обязательные инструменты

2.1.1. Программное обеспечение

Эти программы требуются перед тем, как вы сможете с пользой поработать с документацией FreeBSD, и они позволят вам преобразовать документацию в HTML, обычный текст и формат RTF. Все они включены в порт textproc/docproj.

SP (textproc/sp)

Набор приложений, включающий проверяющий анализатор SGML и нормализатор SGML.

Jade (textproc/jade)

Реализация DSSSL. Используется для преобразования размеченных документов в другие форматы, включая HTML и TeX.

Tidy (www/tidy)

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

Links (www/links)

WWW-браузер, который может также преобразовывать файлы HTML в обычный текст.

peps (graphics/peps)

В часть документации включены графические изображения, некоторые из которых хранятся в виде файлов EPS. Они должны быть преобразованы в PNG для того, чтобы большинство веб-браузеров могли бы их выводить на экран.


2.1.2. DTD и сущности

В FDP используются наборы сущностей и разные DTD. Перед тем, как вы сможете работать с документацией, их нужно установить.

HTML DTD (textproc/html)

HTML представляет собой язык разметки, выбранный для World Wide Web и используемый для веб-сервера FreeBSD.

DocBook DTD (textproc/docbook)

DocBook разработан для разметки технической документации. Вся документация FreeBSD написана на DocBook.

Сущности ISO 8879 (textproc/iso8879)

19 из наборов символьных сущностей ISO 8879:1986 используются во многих DTD. Сюда включены именования математических символов, дополнительные символы в наборе символов ''Latin'' (акценты, диакритические символы, и так далее) и греческие символы.


2.1.3. Таблицы стилей

Таблицы стилей используются при преобразовании и форматировании документации для вывода на экран, печати и так далее.

Модульные таблицы стилей DocBook (textproc/dsssl-docbook-modular)

Модульные таблицы стилей DocBook используются при преобразовании документации, размеченной в DocBook, в другие форматы, такие, как HTML или RTF.


2.2. Необязательные инструменты

Вам не обязательно устанавливать ничего из перечисляемого. Однако вам может оказаться проще работать с документацией, если вы это сделаете и это даст вам больше гибкости при генерации выдачи в различных возможных форматах.


2.2.1. Программное обеспечение

JadeTeX и teTeX (print/jadetex и print/teTeX)

Jade и teTeX используются для преобразования документов DocBook в форматы DVI, Postscript и PDF. Для этого нужны макросы JadeTeX.

Если вы не собираетесь преобразовывать вашу документацию в один из этих форматов (то есть вам достаточно HTML, обычного текста и RTF), то вам не нужно устанавливать JadeTeX и teTeX. Это может значительно сэкономить дисковое пространство и время, так как teTeX имеет примерный объем в 30МБ.

Важно: Если вы решите установить JadeTeX и teTeX, то вам потребуется настроить teTeX после установки JadeTeX. print/jadetex/pkg-message содержит подробные инструкции, описывающие, что вам нужно делать.

Emacs или XEmacs (editors/emacs или editors/emacs)

Оба этих текстовых редактора используют специальный режим для работы с документами, размеченными в соответствии с SGML DTD. Этот режим включает команды для уменьшения требуемого ручного набора и помогает уменьшить вероятность появления ошибок.

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

Если у кого-то есть рекомендации касательно дополнительного программного обеспечения, могущего быть полезным при манипуляциях с документами SGML, пожалуйста, напишите на адрес Группа Менеджеров Дерева Документации FreeBSD , чтобы они могли быть добавлены в этот список.


Глава 3. Учебник SGML

Основной объем документации FDP написан в приложениях SGML. В этой главе в точности описывается, что это значит и как читать и понимать исходный текст документации, а также некоторые из приемов SGML, применение которых вы увидите в документации.

Часть этого раздела была написана по мотивам Начал работы с DocBook от Марка Галасси (Mark Galassi).


3.1. Обзор

Были времена, когда с электронным текстом работать было просто. Вы примерно знали, в каком наборе символов был написан ваш документ (ASCII, EBCDIC или в каком-то другом), но этого было достаточно. Текст был текстом, и то, что вы видели, то и получали. Без украшательств, без форматирования, бездумно.

Несомненно, этого было недостаточно. Как только у вас появляется текст в формате, понимаемом машиной, вы ожидаете, что машины могут использовать его и работать с ним более разумно. Вы хотели бы указывать, что некоторые фразы должны быть выделены или добавлены к словарю, или быть гиперссылками. Вы можете захотеть, чтобы имена файлов показывались шрифтом ''пишущей машинки'' для просмотра на экране и ''наклонным'' при печати, и любым другим из мириад других параметров для представления.

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

Более точно, им нужна помощь в определении того, что есть что. Вы или я можем посмотреть на текст

Чтобы удалить /tmp/foo, воспользуйтесь командой rm(1).

% rm /tmp/foo
и с легкостью определить, где здесь имена файлов, а где команды, которые требуются ввести, в каких частях текста стоит ссылка на страницы справочной системы, и так далее. Но компьютер, обрабатывающий документ, этого сделать не может. Для этого нам нужна разметка.

Термин ''разметка'' часто использовался для описания ''добавления важности'' или ''увеличения стоимости''. Термин принимает оба этих смысла в применении к тексту. Разметка является дополнительным текстом, включаемым в документ, некоторым образом отделяемым от содержимого документа, так, чтобы программы, обрабатывающие документ, могут читать разметку и использовать ее при принятии решений о документе. Текстовые редакторы могут скрывать разметку от пользователя, так что пользователь не будет ею смущен.

Дополнительная информация, хранимая в разметке, добавляет важность документу. Добавление разметки к документу обычно должно делаться человеком--в конце концов, если компьютеры могут распознавать текст достаточно успешно для того, чтобы добавить разметку, то нет нужды добавляться ее сразу. Это увеличивает стоимость (то есть требуемые усилия) создания документа.

Предыдущий пример представлен в этом документе примерно так;

<para>Для удаления <filename>/tmp/foo</filename>, воспользуйтесь командой
  &man.rm.1;.</para>

<screen>&prompt.user; <userinput>rm /tmp/foo</userinput></screen>

Как вы можете видеть, разметка четко отделена от содержимого.

Очевидно, что если вы собираетесь использовать разметку, то вам нужно определить, что она значит, и как она должна интерпретироваться. Вам требуется язык разметки, которому вы можете следовать при разметке ваших документов.

Конечно, одного языка разметки может оказаться недостаточно. Язык разметки для технической документации имеет весьма значительно отличающиеся требования от языка разметки, используемого для кулинарных рецептов. Он, в свою очередь, будет сильно отличаться от языка разметки, используемого для поэзии. На самом деле в первую очередь вам нужен первичный язык, который вы будете использовать для написания этих других языков разметки. Вам нужен метаязык разметки.

И это именно то, чем является Standard Generalised Markup Language (SGML). Многие языки разметки были написаны на SGML, включая два наиболее часто используемые в FDP, HTML и DocBook.

Определение каждого языка более правильно называется Определением Типа Документа (Document Type Definition - DTD). DTD задает имена элементов, которые могут использоваться, в каком порядке они следуют (и может ли некоторая разметка использоваться внутри другой) и связанную с этим информацию. Иногда DTD называют приложением SGML.

DTD является полной спецификацией всех возможных элементов, порядка их следования, какие элементы являются обязательными, какие нет, и так далее. Это позволяет написать лексический анализатор SGML, читающий DTD и документ, который, как предполагается, соответствует этому DTD. Затем анализатор может подтвердить, все ли документы, требуемые DTD, располагаются в документе в правильном порядке, и есть ли ошибки в разметке. Обычно это называется ''проверкой документа''.

Замечание: Эта обработка просто проверяет, что набор элементов, их порядок и так далее. соответствует тому, что перечислено в DTD. При этом не проверяется, используете ли вы разметку, подходящую к содержимому. Если вы попытались выделить все имена файлов в вашем документе как имена функций, то лексический анализатор не укажет, что это ошибка (конечно, при этом предполагается, что ваш DTD задает элементы для имен файлов и функций, и они могут появляться в одном и том же месте).

Скорее всего, что больше всего посылок в Проект Документирования будет состоять из содержимого, размеченного в HTML or DocBook, а не в альтернативных DTD. По этой причине эта книга не будет затрагивать вопросов написания DTD.


3.2. Элементы, метки и атрибуты

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

Ваша документация (вне зависимости от того, представляет ли она собой одну веб-страницу или большую книгу) состоит из содержимого. Это содержимое затем разбивается (а потом разбивается еще) на элементы. Назначением добавления разметки является именование и идентификация границ этих элементов для дальнейшей обработки.

Например, рассмотрим типичную книгу. На самом верхнем уровне книга сама по себе является элементом. Этот элемент ''book'', естественно, содержит главы, которые будут элементами в своем смысле. Каждая глава будет содержать большее количество элементов, таких, как параграфы, цитаты и примечания. Каждый параграф может содержать дополнительные элементы, идентифицирующие содержимое, которое может являться прямой речью или именем героя в рассказе.

Вы можете представлять это как ''дробление'' содержимого. На самом верхнем уровне у вас есть один кусок, книга. Если взглянуть немного глубже, вы получите большее количество частей, или отдельных глав. Они дробятся дальше на параграфы, примечания, имена героев и так далее.

Заметьте, как вы можете провести такое разделение между разными элементами содержимого без обращения к терминам SGML. Это на самом деле удивительно понятно. Вы можете сделать это разноцветной ручкой и печатной книгой, используя разные цвета для выделения разных частей содержимого.

Конечно, у нас нет цветной электронной ручки, так что нам нужен какой-то другой способ выделения того, к какому элементу принадлежит каждая часть содержимого. В языках, написанных на SGML (например, HTML и DocBook) это делается в терминах меток.

Метка используется для указания того, где начинается некоторый элемент, и где он кончается. Метка не является частью самого элемента. Так как каждый DTD был написан для разметки специфичного типа информации, каждый может распознавать различные элементы, и поэтому имеет разные названия для меток.

Для элемента с именем element-name начальная метка обычно будет выглядеть как <element-name>. Соответствующей закрывающей меткой для этого элемента будет </element-name>.

Пример 3-1. Использование элемента (начальная и конечная метки)

В HTML есть элемент p для указания того, что содержимое, включенное в него, является параграфом. Этот элемент имеет как начальную, так и конечную метки.

<p>Это параграф.  Он начинается с начальной
  метки для элемента 'p' и заканчивается конечной меткой для элемента
  'p'.</p>

<p>Это другой параграф.  Но он гораздо короче.</p>

Не все элементы требуют конечной метки. Некоторые элементы не имеют содержимого. К примеру, в HTML вы можете указать, что хотите включить в документ горизонтальную линию. Очевидно, что у этой строки нет содержимого, так что для этого элемента требуется только начальная метка.

Пример 3-2. Использование элемента (только начальная метка)

В HTML имеется элемент для горизонтальной линии, который называется hr. Этот элемент не окружает содержимое, так что имеет только начальную метку.

<p>Это параграф.</p>

<hr>

<p>Это другой параграф.  Горизонтальная линия отделяет его от предыдущего
  параграфа.</p>

Хотя это сейчас не очевидно, но элементы могут включать другие элементы. В примере с книгой ранее, элемент книга содержал все элементы главы, которые, в свою очередь, содержали все элементы параграфы и так далее.

Пример 3-3. Элементы внутри элементов; <em>

<p>Это простой <em>параграф</em>, в котором
  некоторые <em>слова</em> были <em>выделены</em>.</p>

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

Важно: Многие часто путают понятия меток и элементов, и используют эти термины, как если бы они были синонимами. Это не так.

Элемент является концептуальной частью вашего документа. Элемент имеет определенное начало и конец. Метки отмечают, где элемент начинается и где он кончается.

Когда документ (или кто-то, знающие о SGML) ссылается на ''метку <p>'', то имеется в виду текст, состоящий из трех символов <, p и >. Но фраза ''элемент <p>'' обозначает весь элемент.

Это тонкое отличие. Но имейте его в виду.

У элементов могут иметься атрибуты. У атрибута имеется название и значение, и он используется для добавления дополнительной информации к элементу. Это может быть информация о том, как должно быть преобразовано содержимое для вывода на печать, или это может быть что-то, уникальным образом идентифицирующее элемент, или что-то еще.

Атрибуты элемента пишутся внутри начальной метки этого элемента и принимают форму название-атрибута="значение атрибута".

В последних версиях HTML элемент <p> имеет атрибут, под названием align, который задает выравнивание (по отношению к границам) для параграфа программе вывода HTML.

Атрибут align может принимать одно из четырех предопределенных значений, left, center, right и justify. Если атрибут не указан, то по умолчанию используется left.

Пример 3-4. Использование элемента с атрибутом

<p align="left">Включение атрибута
  выравнивания для этого параграфа было излишним, так как по умолчанию
  используется выравнивание по левой границе.</p>

<p align="center">Это может появиться по центру.</p>

Некоторые атрибуты будут воспринимать только конкретные значения, такие, как left или justify. Другие позволят вам задать все, что угодно. Если вам нужно включить двойные кавычки (") в атрибут, то заключите значение атрибута в одинарные кавычки.

Пример 3-5. Атрибуты в одинарных кавычках

<p align='right'>Я справа!</p>

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

Информация об аттрибутах, элементах, и тэгах хранится в SGML каталогах. Различные инструменты Проекта используют эти каталоги для проверки Вашей работы. Утилиты из порта textproc/docproj включают множество различных SGML каталогов. Проект Документирования FreeBSD также имеет свой набор каталогов. И ваши утилиты должны знать об обоих видах SGML каталогов.


3.2.1. Упражнения...

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

  1. Сгрузите и установите textproc/docproj из системы портов FreeBSD. Это мета-порт, который должен сгрузить и установить все программы и сопутствующие файлы, которые используются в Проекте Документирования.

  2. Добавьте команды для установки значения переменной SGML_CATALOG_FILES в ваши файлы запуска командного процессора. (Если Вы не работаете над английской версией документации, то Вы вероятнее всего захотите указать правильный путь к каталогу для Вашего языка.)

    Пример 3-6. .profile для пользователей sh(1) и bash(1)

    SGML_ROOT=/usr/local/share/sgml    
    SGML_CATALOG_FILES=${SGML_ROOT}/jade/catalog
    SGML_CATALOG_FILES=${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=/usr/doc/share/sgml/catalog:$SGML_CATALOG_FILES
    SGML_CATALOG_FILES=/usr/doc/en_US.ISO8859-1/share/sgml/catalog:$SGML_CATALOG_FILES
    export SGML_CATALOG_FILES
    

    Пример 3-7. .cshrc, для пользователей csh(1) и tcsh(1)

    setenv SGML_ROOT /usr/local/share/sgml
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/jade/catalog
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/iso8879/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/html/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES ${SGML_ROOT}/docbook/4.1/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES /usr/doc/share/sgml/catalog:$SGML_CATALOG_FILES
    setenv SGML_CATALOG_FILES /usr/doc/en_US.ISO8859-1/share/sgml/catalog:$SGML_CATALOG_FILES
    

    Затем либо выйдите из системы, а затем войдите снова, либо запустите эти команды из командной строки для установки значений переменных.

  1. Создайте example.sgml и введите следующий текст;

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    
    <html>
      <head>    
        <title>Пример файла HTML</title>
      </head>
    
      <body>    
        <p>Это параграф, содержащий некоторый текст.</p>
    
        <p>В этом параграфе содержится дополнительный текст.</p>
    
        <p align="right">Этот параграф может быть выровнен по правому краю.</p>
      </body>
    </html>
    
  2. Попробуйте выполнить проверку файла при помощи лексического анализатора SGML.

    Частью textproc/docproj является проверяющий лексический анализатор nsgmls. Обычно nsgmls считывает документ, размеченный в соответствии с SGML DTD и возвращает копию Набора Информации о Структуре Элементов документа (ESIS - Element Structure Information Set), но это на данный момент не важно.

    Однако когда nsgmls передается параметр -s, то обычный вывод nsgmls подавляется и печатаются только сообщения об ошибках. Это делает его полезным для проверки правильности вашего документа.

    Воспользуйтесь nsgmls для проверки правильности вашего документа;

    % nsgmls -s example.sgml
    

    Как вы увидите, nsgmls отработает без вывода какой-либо диагностики. Это значит, что ваш документ успешно проверен.

  3. Посмотрите, что случится, если пропущены требуемые элементы. Попробуйте удалить метки <title> и </title>, а затем выполнить проверку повторно.

    % nsgmls -s example.sgml
    nsgmls:example.sgml:5:4:E: character data is not allowed here
    nsgmls:example.sgml:6:8:E: end tag for "HEAD" which is not finished
    

    Вывод с сообщениями об ошибках в nsgmls организован в группы, разделенные двоеточиями, или столбцы.

    Столбец Значение
    1 Название программы, обнаружившей ошибку. Это всегда будет nsgmls.
    2 Имя файла, содержащего ошибку.
    3 Номер строки, в которой появилась ошибка.
    4 Номер колонки, в которой появилась ошибка.
    5 Однобуквенный код, обозначающий природу сообщения. I обозначает информационное сообщение, W для предупреждений и E для ошибок [a] и X для перекрестных ссылок. Как видите, это сообщения об ошибках.
    6 Текст диагностического сообщения.
    Примечания:
    a. Пятая колонка выводится не всегда. nsgmls -sv выдает nsgmls:I: SP version "1.3" (это зависит от установленной версии). Как вы можете видеть, это информационное сообщение.

    Просто опускание меток <title> приведет к генерации 2 разных ошибок.

    Первая ошибка указывает на то, что содержимое (в этом случае символы, а не начальная метка элемента) появилось в том мест, где лексический анализатор ожидал нечто другое. В этом случае анализатор ожидал увидеть начальную метку для одного из элементов, уместных внутри <head> (такую, как <title>).

    Вторая ошибка возникла, потому что элементы <head> должны содержать элемент <title>. Так как его нет, то nsgmls полагает, что элемент не был нормально завершен. Однако закрывающая метка указывает, что элемент был закрыт до того, как был завершен.

  4. Верните элемент title обратно.


3.3. Декларация DOCTYPE

В начале каждого создаваемого вами документа должно указываться название DTD, которому он соответствует. Это нужно для того, чтобы лексические анализаторы SGML могли узнать DTD и определить, соответствует ли документ этому DTD.

Эта информация обычно выражается в одной строке, в виде декларации DOCTYPE.

Типичная декларация того, что документ написан в соответствии с версией 4.0 HTML DTD выглядит таким образом;

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN">

В этой строки содержится несколько различных компонент.

<!

Индикатор, который указывает, что это декларация SGML. Эта строка декларирует тип документа.

DOCTYPE

Показывает, что это декларация типа документа SGML.

html

Именует первый элемент, который появится в документе.

PUBLIC "-//W3C//DTD HTML 4.0//EN"

Указывает Формальный Публичный Идентификатор (Formal Public Identifier - FPI) для DTD, которому соответствует этот документ. Ваш лексический анализатор SGML будет использовать его для поиска нужного DTD при обработке этого документа.

PUBLIC не является частью FPI, но указывает процессору SGML, как найти DTD, на который ссылается FPI. Другие способы указания анализатору SGML, как найти DTD, будут показаны позже.

>

Возвращение к документу.


3.3.1. Идентификаторы FPI

Замечание: Вам не нужно это знать, но это полезная информация, которая может помочь вам решить проблемы, когда вам процессор SGML не может найти используемый вами DTD.

FPI должны следовать определенному синтаксису. Этот синтаксис имеет следующий вид;

"Владелец//Ключевое слово Описание//Язык"
Владелец

Указывает владельца FPI.

Если эта строка начинается с ''ISO'', то этим FPI владеет ISO. К примеру, FPI "ISO 8879:1986//ENTITIES Greek Symbols//EN" задает ISO 8879:1986 как владельца набора определений для греческих символов. ISO 8879:1986 является номером ISO для стандарта SGML.

В противном случае эта строка будет выглядеть либо как -//Владелец или +//Владелец (отметьте единственное отличие в начальном + или -).

Если строка начинается с -, то информация о владельце не является зарегистрированной, со знаком + она идентифицируется как зарегистрированная.

ISO 9070:1991 определяет, как генерируются регистрированные имена; они могут порождаться от номера публикации ISO, кода ISBN или кода организации, назначаемого в соответствии с ISO 6523. Кроме того, для назначения регистрированных имен может быть созван регистрационный комитет. Совет ISO передал это в American National Standards Institute (ANSI).

Так как Проект FreeBSD не был зарегистрирован, то строка владельца имеет вид -//FreeBSD. И как вы можете видеть, W3C еще не является регистрированным владельцем.

Ключевое слово

Имеется несколько ключевых слов, которые указывают на тип информации в файле. Некоторыми из наиболее часто употребляемых ключевых слов являются DTD, ELEMENT, ENTITIES и TEXT. DTD используется только для файлов DTD, ELEMENT обычно используется для фрагментов DTD, которые содержат только объекты или декларации элемента. TEXT используется для содержимого SGML (текст и метки).

Описание

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

Язык

Это двухсимвольный код ISO, который идентифицирует естественный язык файла. EN применяется для английского языка.


3.3.1.1. Файлы catalog

Если вы используете указанный выше синтаксис и пытаетесь обработать этот документ при помощи процессора SGML, то процессор каким-то образом преобразовать FPI в имя файла вашего компьютера, в котором находится DTD.

Для этого он может использовать файл каталога. Файл каталога (обычно называемый catalog) состоит из строк, ставящих FPI в соответствие с именами файлов. К примеру, пусть в файле каталога содержится строка;

PUBLIC "-//W3C//DTD HTML 4.0//EN"             "4.0/strict.dtd"

Процессор SGML определит, что нужно взять DTD из файла strict.dtd в подкаталоге 4.0 того каталога, в котором находится файл catalog, содержащий эту строку.

Посмотрите на содержимое файла /usr/local/share/sgml/html/catalog. Это файл каталога, для HTML DTD, которые были установлены как часть порта textproc/docproj.


3.3.1.2. SGML_CATALOG_FILES

Для того, чтобы он нашел файл catalog, вашему процессору SGML нужно указать, где искать. Во многом для этого служат параметры командной строки для указания пути к одному или более каталогам.

Вдобавок вы можете задать переменную SGML_CATALOG_FILES для указания на файлы. Эта переменная окружения должна состоять из списка файлов каталогов, разделенных двоеточиями (включая их полные маршруты).

Как правило, вам будет нужно включить следующие файлы;

  • /usr/local/share/sgml/docbook/4.1/catalog

  • /usr/local/share/sgml/html/catalog

  • /usr/local/share/sgml/iso8879/catalog

  • /usr/local/share/sgml/jade/catalog

У вас это уже должно быть сделано.


3.3.2. Альтернативы FPI

Вместо использования PFI для указания DTD, которому соответствует документ (и указания таким образом файла системы, в котором находится DTD), вы можете задать имя файла явным образом.

Применяемый при этом синтаксис несколько отличается:

<!DOCTYPE html SYSTEM "/path/to/file.dtd">

Ключевое слово SYSTEM указывает, что процессор SGML должен найти DTD способом, зависящим от системы. Обычно (но не всегда) это означает, что DTD будет задано как имя файла.

Использование FPI предпочтительно по соображениям переносимости. Вам не нужно будет передавать копию DTD вместе с вашим документом, а если же вы используете механизм SYSTEM, то всем потребуется размещать DTD в том же самом месте.


3.4. Возвращение к SGML

Ранее в этом примере я утверждал, что SGML используется только при написании DTD. Это не совсем так. Есть некоторые элементы синтаксиса SGML, которые вам понадобится использовать в документе. К примеру, в ваш документ могут быть включены комментарии, которые игнорируются лексическим анализатором. Комментарии вводятся с использованием синтаксиса SGML. Другие примеры использования синтаксиса SGML в вашем документе также будут показаны позже.

Очевидно, что вам нужен некоторый способ указания процессору SGML на то, что следующий текст не является элементами документа, но является SGML, который должен быть обработан лексическим анализатором.

Такие разделы отмечаются в вашем документе символами <! ... >. Все между этими разделителями является синтаксисом SGML, который вы можете найти в DTD.

Как вы, может быть, уже обнаружили, декларация DOCTYPE является примером синтаксиса SGML, который вам нужно включить в ваш документ...


3.5. Комментарии

Комментарии являются конструкцией SGML, и обычно имеют смысл только внутри DTD. Однако, как Разд. 3.4 показывает пример, в вашем документе возможно использовать синтаксис SGML.

Разделителем для комментариев SGML является строка ''--''. Первое появление такой строки открывает комментарий, а второе его закрывает.

Пример 3-8. Комментарий SGML общего вида

<!-- Тестовый комментарий -->
<!-- Это находится внутри комментария -->

<!-- Это еще один комментарий    -->

<!-- Это один из способов
     создания многострочных комментариев -->

<!-- Это другой способ   --
  -- создания многострочных комментариев -->

Если ранее вы использовали HTML, вы можете заметить различия в правилах для комментариев. В частности, вы можете думать, что строчка <!-- открывает комментарий, и закрывается только -->.

Это не так. Во множестве веб-браузеров анализаторы HTML работают неправильно, и воспринимают такой синтаксис как правильный. Однако анализаторы SGML, используемые в Проекте Документирования, гораздо более строги, и не пропустят документы, в которых сделана эта ошибка.

Пример 3-9. Комментарии SGML с ошибкой

<!-- Это находится внутри комментария --

     ЭТО ВНЕ КОММЕНТАРИЯ!

  -- снова внутри комментария -->

Анализатор SGML будет интерпретировать, как будто на самом деле это было так;

<!ЭТО ВНЕ КОММЕНТАРИЯ>

Это неправильный SGML, и может дать непонятные сообщения об ошибках.

<!--------------- Это очень плохая идея --------------->

Как и указано в примере, не пишите такие комментарии.

<!--===================================================-->

Такой подход (несколько) лучше, но все же может запутать новичков в SGML.


3.5.1. Упражнения...

  1. Добавьте несколько комментарии в example.sgml и проверьте файл при помощи nsgmls.

  2. Добавьте несколько неправильных комментариев в example.sgml и посмотрите на сообщения об ошибках, которые выдает nsgmls, когда встречает неправильный комментарий.


3.6. Сущности

Сущности являются механизмом для назначения имен частям содержимого. Когда анализатор SGML обрабатывает ваш документ, все сущности, которые он найдет, заменяются на их содержимое.

Это хороший способ иметь повторно используемые легко заменяемые куски содержимого в вашем документе SGML. Также это является единственным способом включить один размеченный файл в другой средствами SGML.

Имеется два типа сущностей, которые могут быть использованы в двух различных ситуациях; сущности общего вида и параметризированые сущности.


3.6.1. Сущности общего вида

Вы не можете использовать сущности общего вида в содержимом SGML (если только вы не определили их в нем). Они могут использоваться только в вашем документе. Сравните это с параметризированными сущностями.

Каждая сущность общего вида имеет имя. Когда вы хотите сослаться на такую сущность (и таким образом включить некоторый текст, который она представляет, в ваш документ), вы пишете &имя-сущности;. К примеру, положим, что у вас есть сущность под названием current.version, которая расширяется в номер текущей версии вашего продукта. Вы можете написать;

<para>Текущей версией нашего продукта является
  &current.version;.</para>

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

Вы можете также использовать сущности общего вида для ввода символов, которые вы не можете включить в документ SGML никаким другим способом. Например, символы < и & не могут появиться в документе SGML в явном виде. Когда анализатор SGML видит символ <, он полагает, что это начало метки (начальной или конечной), а когда обнаруживает символ &, то полагает, что последующий текст будет являться именем сущности.

К счастью, вы можете использовать две сущности общего вида &lt; и &amp;, когда хотите включить в текст один из этих символов

Сущность общего назначения может быть определена только в содержимом SGML. Как правило, это делается сразу же после декларации DOCTYPE.

Пример 3-10. Задание сущностей общего назначения

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY current.version    "3.0-RELEASE">
<!ENTITY last.version       "2.2.7-RELEASE">
]>

Заметьте, как была расширена декларация DOCTYPE путем добавления квадратных скобок в конце первой строки. Затем в последующих двух строках до закрывающих квадратных скобок, были заданы две сущности, а затем закрыта декларация DOCTYPE.

Квадратные скобки необходимы для указания того, что мы расширяем DTD, на которое ссылается декларация DOCTYPE.


3.6.2. Параметризированные сущности

Как и сущности общего назначения, параметризированные сущности могут использоваться только в контексте SGML.

Параметризированные сущности определяются способом, похожим на определение сущностей общего назначения. Однако вместо использования &имени-сущности; для ссылки на нее, используется %имя-сущности; [1]. Определение также включает % между ключевым словом ENTITY и именем сущности.

Пример 3-11. Задание параметризированных сущностей

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % param.some "some">
<!ENTITY % param.text "text">
<!ENTITY % param.new  "%param.some more %param.text">

<!-- %param.new теперь содержит "some more text" -->
]>

Это может выглядеть не часто полезным. Но это так.


3.6.3. Упражнения...

  1. Добавьте сущность общего назначения в example.sgml.

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
    <!ENTITY version "1.1">
    ]>  
    
    <html>
      <head>    
        <title>Пример файла HTML</title>
      </head>
    
      <!-- Вы можете также поместить здесь комментарии -->
    
      <body>    
        <p>Этот параграф содержит некоторый текст.</p>
    
        <p>Этот параграф содержит некоторый дополнительный текст.</p>
    
        <p align="right">Этот параграф может быть выравнен по правому краю.</p>
    
        <p>Текущая версия этого документа: &version;</p>
      </body>
    </html>
    
  2. Проверьте документ посредством nsgmls

  3. Загрузите example.sgml в ваш веб-браузер (вам может потребоваться скопировать его в example.html перед тем, как вам браузер распознает его в качестве документа HTML).

    Если только ваш браузер не сложен, вы не увидите ссылку на сущность &version;, замененную на номер версии. Большинство веб-браузеров имеют весьма упрощенные анализаторы, которые не в полной мере обрабатывают SGML [2].

  4. Решение заключается в нормализации вашего документа при помощи нормализатора SGML. Нормализатор читает правильный SGML и выводит соответствующий правильный SGML, который был некоторым образом преобразован. Одним из способов преобразования SGML нормализатором заключается в расширении всех ссылок на сущности в документе заменой их на соответствующий текст.

    Для этого вы можете использовать sgmlnorm.

    % sgmlnorm example.sgml > example.html
    

    Вы должны найти нормализованную (то есть с расширенными ссылками на сущности) копию вашего документа в example.html, готовую для загрузки в ваш веб-браузер.

  5. Если вы посмотрите на вывод команды sgmlnorm, то увидите, что в его начале не включена декларация DOCTYPE. Для ее включения вам нужно использовать опцию -d;

    % sgmlnorm -d example.sgml > example.html
    

3.7. Использование сущностей для включения файлов

Сущности (как общего назначения, так и параметризованные), в частности полезны для включение одного файла в другой.


3.7.1. Использование сущностей общего назначения для включения файлов

Предположим, что у вас есть есть некоторое содержимое для книги SGML, организованное в виде файлов, по одному на главу, под именами chapter1.sgml, chapter2.sgml и так далее, и файл book.sgml, который будет содержать эти главы.

Для использования содержимого этих файлов в качестве значений для ваших сущностей вы объявляете их при помощи ключевого слова SYSTEM. Это указывает анализатору SGML на использование содержимого указанного файла в качестве значения сущности.

Пример 3-12. Использование сущностей общего назначения для включения файлов

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY chapter.1 SYSTEM "chapter1.sgml">
<!ENTITY chapter.2 SYSTEM "chapter2.sgml">
<!ENTITY chapter.3 SYSTEM "chapter3.sgml">
<!-- И так далее -->
]>

<html>
  <!-- Используем сущности для подгрузки глав -->

  &chapter.1;
  &chapter.2;
  &chapter.3;
</html>

Внимание: При использовании сущностей общего назначения для включения других файлов в документ, включаемые файлы (chapter1.sgml, chapter2.sgml и так далее) не должны начинаться с декларации DOCTYPE. Это синтаксическая ошибка.


3.7.2. Использование параметризированных сущностей для включения файлов

Вспомните, что параметризированные сущности могут использоваться только внутри контекста SGML. Тогда зачем вам может потребоваться включать файл внутрь контекста SGML?

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

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

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

Вместо этого поместите определения сущностей общего назначения в один файл и воспользуйтесь параметризированной сущностью для включения этого файла в ваш документ.

Пример 3-13. Использование параметризированных сущностей для включения файлов

Во-первых, поместите определения ваших сущностей в отдельный файл с именем chapters.ent. Этот файл содержит следующее;

<!ENTITY chapter.1 SYSTEM "chapter1.sgml">
<!ENTITY chapter.2 SYSTEM "chapter2.sgml">
<!ENTITY chapter.3 SYSTEM "chapter3.sgml">

Теперь создайте параметризованную сущность для обращения к содержимому файла. Потом используйте параметризованную сущность для загрузки файла в документ, который сделает сущности общего назначения доступными для использования. Теперь используйте сущности общего назначения, как и раньше;

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!-- Определение параметризованной сущности для подгрузки сущностей общего
     назначения -->
<!ENTITY % chapters SYSTEM "chapters.ent">

<!-- А теперь используем параметризованную сущность для загрузки их в файл -->
%chapters;
]>

<html>
  &chapter.1;
  &chapter.2;
  &chapter.3;
</html>

3.7.3. Упражнения...

3.7.3.1. Использование сущностей общего назначения для включения файлов

  1. Создайте три файла, para1.sgml, para2.sgml и para3.sgml.

    В каждый файл поместите примерно такой текст;

    <p>Это первый параграф.</p>
    
  2. Отредактируйте example.sgml так, чтобы он выглядел примерно так;

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
    <!ENTITY version "1.1">
    <!ENTITY para1 SYSTEM "para1.sgml">
    <!ENTITY para2 SYSTEM "para2.sgml">
    <!ENTITY para3 SYSTEM "para3.sgml">
    ]>
    
    <html>
      <head>
        <title>Пример файла HTML</title>
      </head>
    
      <body>
        <p>Текущая версия этого документа: &version;</p>
    
        &para1;
        &para2;
        &para3;
      </body>
    </html>
    
  3. Сгенерируйте файл example.html, выполнив нормализацию example.sgml.

    % sgmlnorm -d example.sgml > example.html
    
  4. Загрузите example.html в ваш веб-браузер и проверьте, что файлы с именами paran.sgml были включены в example.html.


3.7.3.2. Использование параметризированных сущностей для включения файлов

Замечание: Сначала вы должны выполнить предыдущие шаги.

  1. Отредактируйте example.sgml так, чтобы он выглядел примерно так;

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
    <!ENTITY % entities SYSTEM "entities.sgml"> %entities;
    ]>
    
    <html>
      <head>
        <title>Пример файла HTML</title>
      </head>
    
      <body>
        <p>Текущая версия этого документа: &version;</p>
    
        &para1;
        &para2;
        &para3;
      </body>
    </html>
    
  2. Создайте новый файл, entities.sgml, с таким содержимым:

    <!ENTITY version "1.1">
    <!ENTITY para1 SYSTEM "para1.sgml">
    <!ENTITY para2 SYSTEM "para2.sgml">
    <!ENTITY para3 SYSTEM "para3.sgml">
    
  3. Сгенерируйте файл example.html, выполнив нормализацию файла example.sgml.

    % sgmlnorm -d example.sgml > example.html
    
  4. Загрузите файл example.html в ваш веб-браузер и проверьте, что файлы paran.sgml были включены в example.html.


3.8. Отмеченные разделы

SGML дает механизм для отметки отдельных частей документа, которые должны быть обработаны особым образом. Это называется ''пометкой разделов''.

Пример 3-14. Структура отмеченного раздела

<![ KEYWORD [
  Содержимое отмеченного раздела
]]>

Как вы и ожидали, являясь конструкцией SGML, помеченный раздел начинается с <!.

Первая квадратная скобка отмечает начало помеченного раздела.

KEYWORD указывает на то, как этот помеченный раздел должен быть обработан анализатором.

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

Помеченный раздел заканчивается двумя закрывающимися квадратными скобками, и затем выполняется переключение с SGML на контекст документа при помощи знака >


3.8.1. Ключевые слова помеченного раздела

3.8.1.1. CDATA, RCDATA

Эти ключевые слова отмечают модель содержимого отмеченных разделов и позволяет вам менять ее на отличную от используемую по умолчанию.

Когда анализатор SGML обрабатывает документ, он отслеживает так называемую ''модель содержимого''.

Если говорить кратко, то модель содержимого описывает, какой тип содержимого анализатор должен ожидать и что будет делать, когда его обнаружит.

Скорее всего, наиболее полезными для вас окажутся две модели содержимого, CDATA и RCDATA.

CDATA означает ''Character Data'' (символьные данные). Если анализатор находится в этой модели содержимого, то он ожидает символы, и только символы. В этой модели символы < и & теряют свой особый смысл и будут интерпретироваться как обычные символы.

RCDATA означает ''Entity references and character data'' (ссылки на сущности и символьные данные). Если анализатор находится в этой модели содержимого, то будут ожидаться символы и сущности. < теряет свой особый статус, но & все же будет восприниматься как начало сущности общего назначения.

В частности, это полезно, если вы включаете без изменений некоторый текст, который содержит много символов < и &. Хотя вы можете просмотреть весь текст и проверить, что все < преобразованы в &lt;, а все & заменены на &amp;, может быть легче отметить раздел как содержащий только CDATA. Когда анализатор SGML встретит это, он будет игнорировать символы < и &, присутствующие в содержимом.

Когда Вы используете CDATA или RCDATA из примеров, помните о том, что содержимое CDATA не проверяется на правильность. Вы должны проверить его другим способом. Например, Вы можете написать пример в другом документе, проверить его, а потом скопировать его в Вашу область CDATA.

Пример 3-15. Использование разделов, помеченных как CDATA

<para>Вот пример того, как вы должны включать
  некоторый текст, содержащий множество символов &lt; и &amp;.  Текст
  в примере является фрагментом HTML.  Окружающие текст (<para> и
  <programlisting>) из DocBook.</para>

<programlisting>
  <![ CDATA [  
    <p>Это пример, показывающий вам некоторые элементы HTML.  Так как угловые
      скобки используются так часто, то проще всего указать, что весь пример
      является разделом, помеченным как CDATA, чем использовать имена сущностей
      для левых и правых угловых скобок по всему тексту.</p>

    <ul>
      <li>Это элемент списка</li>
      <li>Это второй элемент списка</li>
      <li>Это третий элемент списка</li>
    </ul>

    <p>Это конец примера.</p>
  ]]>
</programlisting>

Если вы посмотрите исходный текст этого документа, вы увидите использование этой техники.


3.8.1.2. INCLUDE и IGNORE

Если ключевым словом является INCLUDE, то содержимое отмеченного раздела будет обрабатываться. Если ключевым словом является IGNORE, то помеченный раздел игнорируется и не будет обрабатываться. Он не будет попадать в выходной документ.

Пример 3-16. Использование INCLUDE и IGNORE в помеченных разделах

<![ INCLUDE [
  Этот текст будет обработан и включен.
]]>

<![ IGNORE [
  Этот текст не будет обработан и включен.
]]>

Само по себе это не очень полезно. Если вы захотите удалить текст из вашего документа, вы можете его вырезать или поместить в комментарии.

Это становится более полезным, когда вы поймете, что сможете использовать параметризированные сущности для управления этим. Запомните, что параметризированные сущности могут быть использованы только в контексте SGML, а ключевое слово помеченного раздела является контекстом SGML.

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

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

Когда вы захотите сделать версию документа для печати, измените значение параметризованной сущности на IGNORE и повторно обработайте документ.

Пример 3-17. Использование параметризованной сущности для управления помеченным разделом

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
<!ENTITY % electronic.copy "INCLUDE">    
]]>

...

<![ %electronic.copy [
  Этот текст должен появиться только в электронной
  версии документа.
]]>

При создании версии для печати измените определение сущности на следующее;

<!ENTITY % electronic.copy "IGNORE">

При повторной обработке документа помеченные разделы, которые используют %electronic.copy в качестве ключевого слова, будут проигнорированы.


3.8.2. Упражнения...

  1. Создайте новый файл, section.sgml, в котором содержится следующее;

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" [
    <!ENTITY % text.output "INCLUDE">
    ]>
    
    <html>
      <head>
        <title>Пример использования помеченных разделов</title>
      </head>
    
      <body> 
        <p>Этот параграф <![ CDATA [содержит много символов <
          (< < < < <), так что проще заключить его в раздел,
          помеченный как CDATA ]]></p>
    
        <![ IGNORE [
        <p>Этот параграф определенно не будет включен в выходной
          документ.</p>
        ]]>
    
        <![ %text.output [
        <p>Этот параграф может быть включен в выходной документ, а может там и
          не оказаться.</p>
    
        <p>Его появление контролируется параметризованной сущностью
          %text.output.</p>  
        ]]>
      </body>
    </html>
    
  2. Выполните нормализацию этого файла при помощи sgmlnorm(1) и проверьте выходной документ. Отметьте, какие параграфы появились, какие исчезли, и что случилось с содержимым раздела, помеченного как CDATA.

  3. Измените определение сущности text.output с INCLUDE на IGNORE. Повторно выполните нормализацию файла и посмотрите, что изменилось в выходном документе.


3.9. Заключение

Это заключительная часть этого учебника по SGML. По причинам экономии места и сложности некоторых вопросов, они не были глубоко рассмотрены (или мы их совсем не касались). Однако в предшествующих разделах SGML рассмотрен достаточно для того, чтобы вы смогли работать с документацией FDP.


Глава 4. Разметка SGML

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

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

Это не исчерпывающий список элементов, так как это стало бы простым повторением документации по каждому языку. Предназначение этого раздела заключается в перечислении тех элементов, которые в первую очередь будут полезными для вас. Если у вас есть вопрос по поводу наилучшей разметки конкретного текста, пожалуйста, пошлите его по адресу Список рассылки Проекта Документации FreeBSD

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


4.1. HTML

HTML, HyperText Markup Language (Язык Гипертекстовой Разметки), применяется в World Wide Web. Более полная информация может быть найдена по адресу <URL:http://www.w3.org/>.

HTML применяется для разметки страниц на веб-сервере FreeBSD. Он не применяется (как правило) для разметки другой документации, так как DocBook предоставляет на выбор гораздо более богатый набор элементов. Соответственно, обычно вы встречаетесь только со страницами HTML, если вы пишете для веб-сайта.

HTML прошел через последовательность версий, 1, 2, 3.0, 3.2 и самую последнюю, 4.0 (которая есть как в строгом, так и нежестком вариантах).

DTD для HTML доступны из коллекции портов через порт textproc/html. Они автоматически устанавливаются как часть порта textproc/docproj.


4.1.1. Формальный Публичный Идентификатор (Formal Public Identifier - FPI)

Существует несколько FPI для HTML, зависящих от версии (также называемой уровнем) HTML, которому вы хотите объявить, что ваш документ соответствует.

Основная масса документов HTML на веб-сайте FreeBSD соответствует простой версии HTML 4.0.

PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

4.1.2. Элементы разделов

Документ HTML обычно делится на два раздела. Первый раздел, называемый заголовком (head), содержит мета-информацию о документе, такую, как его название, имя автора, родительский документ и так далее. Второй раздел, тело (body), включает содержимое, которое будет выводиться пользователю.

Эти разделы помечаются элементами <head> и <body> соответственно. Эти элементы размещаются внутри элемента <html> самого верхнего уровня.

Пример 4-1. Обычная структура документа HTML

<html>
  <head>
      <title>Заголовок документа</title>
  </head>

  <body>

    ...

  </body>
</html>

4.1.3. Блочные элементы

4.1.3.1. Заголовки

HTML позволяет вам выделять заголовки в вашем документе до шести различных уровней.

Самым большим и наиболее бросающимся в глаза заголовком является <h1>, затем <h2>, продолжая до нисходящей до <h6>.

Элемент содержит текст заголовка.

Пример 4-2. <h1>, <h2> и так далее.

Использование:

<h1>First section</h1>

<!-- Здесь помещается введение документа -->

<h2>Это заголовок первого раздела</h2>

<!-- Здесь размещается содержимое первого раздела -->

<h3>Это заголовок первого подраздела</h3>

<!-- Здесь размещается содержимое первого подраздела -->

<h2>Это заголовок второго раздела</h2>

<!-- Здесь размещается содержимое второго раздела -->

Вообще говоря, на странице HTML должен иметься один заголовок первого уровня (<h1>). Он может содержать много заголовков второго уровня (<h2>), которые, в свою очередь, содержат много заголовков третьего уровня. Каждый элемент <hn> должен иметь тот же самый элемент, но выше по иерархии. Избегайте пропусков в нумерации.

Пример 4-3. Неправильный порядок следования элементов <hn>

Использование:

<h1>Первый раздел</h1>

<!-- Введение документа -->

<h3>Подраздел</h3>

<!-- Это плохо, пропущен <h2> -->

4.1.3.2. Параграфы

HTML поддерживает элемент отдельного параграфа, <p>.

Пример 4-4. <p>

Использование:

<p>Это параграф.  Он может содержать
практически любой другой элемент.</p>

4.1.3.3. Цитирование блока

Цитирование блока это расширенное цитирование из другого документа, который не должен появляться внутри текущего параграфа.

Пример 4-5. <blockquote>

Использование:

<p>Короткий отрывок из Конституции США:</p>

<blockquote>We the People of the United States, in Order to form
  a more perfect Union, establish Justice, insure domestic
  Tranquility, provide for the common defence, promote the general
  Welfare, and secure the Blessings of Liberty to ourselves and our
  Posterity, do ordain and establish this Constitution for the
  United States of America.</blockquote>

4.1.3.4. Списки

Вы можете представить пользователю три типа списков, упорядоченный, неупорядоченный и определений.

Обычно каждый пункт в упорядоченном списке будет пронумерован, когда как каждому пункту в неупорядоченном списке будет предшествовать маркер. Списки определений состоят из двух секций для каждого пункта. Первая секция является определяемым термином, а вторая секция представляет собой определение термина.

Упорядоченные списки помечаются элементом <ol>, неупорядоченные элементом <ul>, а списки определений элементом <dl>.

Упорядоченные и неупорядоченные списки содержат элементы списка, отмечаемые элементом <li>. Элемент списка может содержать текст или может разбиваться на один или большее количество элементов <p>.

Списки определений содержат определяемые термины (<dt>) и собственно определения (<dd>). Определяемый термин может содержать только строчные элементы. Определение может содержать другие блочные элементы.

Пример 4-6. <ul> и <ol>

Использование:

<p>Неупорядоченный список.  Элементам
списка должны предшествовать маркеры.</p>

<ul>
  <li>Первый элемент</li>

  <li>Второй элемент</li>

  <li>Третий элемент</li>
</ul>

<p>Упорядоченный список, с элементами, состоящими из нескольких параграфов.
  Каждый элемент (замечание: но не каждый параграф) будет пронумерован.</p>

<ol>
  <li><p>Это первый элемент.  В нем только один параграф.</p></li>

  <li><p>Это первый параграф второго элемента.</p>

    <p>Это второй параграф второго элемента.</p></li>

  <li><p>Это первый и единственный параграф третьего элемента списка.</p></li>
</ol>

Пример 4-7. Списки определений с <dl>

Использование:

<dl>
  <dt>Термин 1</dt>

  <dd><p>Параграф 1 определения 1.</p>

    <p>Параграф 2 определения 1.</p></dd>

  <dt>Термин 2</dt>

  <dd><p>Параграф 1 определения 2.</p></dd>

  <dt>Термин 3</dt>

  <dd>Параграф 1 определения 3.  Заметьте, что элемент &lt;p&gt;
    в случае единственного параграфа не нужен.</dd>
</dl>

4.1.3.5. Предварительно отформатированный текст

Вы можете указать, что текст должен быть показан пользователю точно в таком виде, как вы его набрали в файле. Обычно это значит, что текст будет выводиться шрифтом фиксированного размера, несколько пробелов не будут объединяться в один и символы окончания строк принимаются во внимание.

Для этого поместите содержимое в элемент <pre>.

Пример 4-8. <pre>

Вы можете использовать <pre> для разметки сообщения электронной почты;

<pre>  From: nik@FreeBSD.org
  To: freebsd-doc@FreeBSD.org
  Subject: New documentation available

  There's a new copy of my primer for contributers to the FreeBSD
  Documentation Project available at

    <URL:http://people.FreeBSD.org/~nik/primer/index.html>

  Comments appreciated.

  N</pre>

4.1.3.6. Таблицы

Замечание: Большинство браузеров, работающих в текстовом режиме (таких, как Lynx), не выводят таблицы достаточно правильно. Если вы рассчитываете на табличный вывод вашего текста, то во избежание путаницы вы должны использовать альтернативную разметку.

Размечайте табличную информацию при помощи элемента <table>. Таблица состоит из одной или большего количества строк (<tr>), каждая из которых содержит одну или большее количество ячеек с данными (<td>). Каждая ячейка может содержать другие блочные элементы, такие, как параграфы или списки. Она может также содержать другую таблицу (такое вложение может быть бесконечным). Если ячейка содержит только один параграф, то вам не нужно включать элемент <p>.

Пример 4-9. Простое использование <table>

Использование:

<p>Это простая таблица 2x2.</p>

<table>
  <tr>
    <td>Верхняя левая ячейка</td>

    <td>Верхняя правая ячейка</td>
  </tr>

  <tr>
    <td>Нижняя левая ячейка</td>

    <td>Нижняя правая ячейка</td>
  </tr>
</table>

Ячейка может занимать несколько строк и столбцов. Для указания этого добавьте атрибуты rowspan и/или colspan со значениями, указывающими количество строк или столбцов, которые должны быть заняты.

Пример 4-10. Использование rowspan

Использование:

<p>Одна высокая тонкая ячейка слева,
  две низкие ячейки за ней справа.</p>

<table>
  <tr>
    <td rowspan="2">Длинная и высокая</td>
  </tr>

  <tr>
    <td>Верхняя ячейка</td>

    <td>Нижняя ячейка</td>
  </tr>
</table>

Пример 4-11. Использование colspan

Использование:

<p>Одна длинная ячейка сверху, две
  короткие ячейки под ней.</p>

<table>
  <tr>
    <td colspan="2">Верхняя ячейка</td>
  </tr>

  <tr>
    <td>Нижняя левая ячейка</td>

    <td>Нижняя правая ячейка</td>
  </tr>
</table>

Пример 4-12. Использование rowspan и colspan одновременно

Использование:

<p>На сетке 3x3 верхний левый блок является
  набором клеток 2x2, объединенных в одну ячейку.
  Остальные клетки нормальные.</p>

<table>
  <tr>
    <td colspan="2" rowspan="2">Верхняя левая большая ячейка</td>

    <td>Верхняя правая клетка</td>
  </tr>

  <tr>
    <!-- Из-за того, что большая ячейка слева объединяется в
     эту строку, первый <td> появится справа -->

    <td>Средняя правая ячейка</td>
  </tr>

  <tr>
    <td>Нижняя левая ячейка</td>

    <td>Нижняя средняя ячейка</td>

    <td>Нижняя правая ячейка</td>
  </tr>
</table>

4.1.4. Строчные элементы

4.1.4.1. Выделяющая информация

В HTML имеется два уровня выделения, <em> и <strong>. <em> предназначен для обычного уровня выделения, а <strong> указывает на более сильное выделение.

Как правило, <em> выводится наклонным, а <strong> жирным шрифтами. Это не всегда так, и вам не следует на это полагаться.

Пример 4-13. <em> и <strong>

Использование:

<p><em>Этот текст</em> выделен, а
  <strong>этот текст</strong> выделен сильно.</p>

4.1.4.2. Жирный и наклонный

Так как в HTML имеется презентационная разметка, вы можете также указать, что указанное содержимое должно быть выведено жирным или наклонным шрифтами. Это элементы <b> и <i> соответственно.

Пример 4-14. <b> и <i>

<p><b>Этот текст</b> выводится жирным, а
  <i>этот текст</i> выводится наклонным шрифтами.</p>

4.1.4.3. Указание текста одинаковой ширины

Если у вас есть текст, который должен быть выведен моноширинным шрифтом (шрифтом пишущей машинки), используйте <tt> (от слова ''teletype'' - телетайп).

Пример 4-15. <tt>

Использование:

<p>Этот документ первоначально создал
  Ник Клэйтон (Nik Clayton), которому можно написать по электронной почте
на адрес <tt>nik@FreeBSD.org</tt>.</p>

4.1.4.4. Размер текста

Вы можете указать, что содержимое должно показываться шрифтами большего или меньшего размеров. Есть три способа сделать это.

  1. Используйте <big> и <small> вокруг содержимого, размер которого вы хотите изменить. Эти метки могут быть вложенными, так, возможно выводить <big><big>этот текст гораздо крупнее</big></big>.

  2. Используйте набор <font> совместно с атрибутом size, установленным в +1 или -1 соответственно. Это будет иметь тот же самый эффект, что и использование <big> или <small>. Однако такое использование не рекомендуется.

  3. Использование <font> вместе с атрибутом size, установленным в значение от 1 до 7. Размер шрифта, используемый по умолчанию, равен 3. Это подход не рекомендуется.

Пример 4-16. <big>, <small> и <font>

В следующих фрагментах выполняется одно и тоже.

<p>Этот текст <small>немного меньше</small>.  А
  этот текст <big>немножко больше</big>.</p>

<p>Этот текст <font size="-1">несколько меньше</font>.  А
  этот  текст <font size="+1">немного крупнее</font.</p>

<p>Этот текст <font size="2">немного мельче</font>.  А
  этот текст <font size="4">немного крупнее</font>.</p>

4.1.5. Ссылки

Замечание: Ссылки также являются внутристрочными элементами.


4.1.5.1. Ссылки на другие документы на WWW

Для того, чтобы включить ссылку на другой документ из Интернет, вы должны знать URL документа, на который хотите сослаться.

Ссылка выделяется элементом <a> и атрибутом href, содержащим URL целевого документа. Содержимое элемента заменяет ссылку и обычно каким-то способом выводится пользователю (подчеркиванием, изменением цвета, другим типом курсора мыши, находящимся над ссылкой, и так далее).

Пример 4-17. Использование <a href="...">

Использование:

<p>Дополнительная информация находится на
  <a href="http://www.FreeBSD.org/">веб-сайте FreeBSD</a>.</p>

Эти ссылки направят пользователя к началу выбранного документа.


4.1.5.2. Ссылки на другие части документов

Ссылка на точку внутри другого документа (или внутри того же самого документа) требует, чтобы автор документа включил метку, на которую вы можете сослаться.

Метки помечаются с помощью <a> и атрибута name вместо href.

Пример 4-18. Использование <a name="...">

Использование:

<p><a name="para1">На</a> этот параграф
  можно сослаться из других мест
  по имени <tt>para1</tt>.</p>

Чтобы сослаться на именованную часть документа, напишите обычную ссылку на тот документ, но включите имя метки после символа #.

Пример 4-19. Ссылка на именованную часть другого документа

Предположим, что пример с para1 расположен в документе с именем foo.html.

<p>Дополнительная информация может быть
  найдена в <a href="foo.html#para1">первом абзаце</a> из
  <tt>foo.html</tt>.</p>

если вы ссылаетесь на именованную метку внутри того же самого документа, то вы можете опустить URL документа, и просто включить имя метки (с предшествующим #).

Пример 4-20. Ссылка на именованную часть того же самого документа

Положим, что пример с para1 расположен в этом документе

<p>Дополнительная информация может быть
  найдена в <a href="#para1">первом абзаце</a> этого
  документа.</p>

4.2. DocBook

DocBook был разработан компаниями HaL Computer Systems и O'Reilly & Associates, как DTD для написания технической документации [3]. С 1998 года его поддержкой занимается DocBook Technical Committee. Поэтому, и в отличие от LinuxDoc и HTML, DocBook очень сильно ориентирован на разметку, описывающую что это, а не на описание того, как это должно выглядеть.

Формально или неформально: Некоторые элементы могут существовать в двух формах, formal и неформальной. Обычно формальная версия элемента будет состоять из заголовка, за которым следует информация о версии элемента. Неформальная форма заголовка не содержит.

DocBook DTD находится в коллекции портов как порт textproc/docbook. Он автоматически устанавливается как часть порта textproc/docproj.


4.2.1. Расширения FreeBSD

Проект Документирования FreeBSD расширил DocBook DTD, добавив некоторые новые элементы. Эти элементы служат для уточнения некоторых элементов разметки.

Когда в списке ниже встречается элемент, специфичный для FreeBSD, это будет явно указано.

В оставшемся тексте этого документа термин ''DocBook'' используется в смысле DocBook DTD, расширенного во FreeBSD.

Замечание: В этих расширениях нет ничего, специфичного для FreeBSD, просто было чувство, что эти расширения оказались полезными для этого конкретного проекта. Если кто-то из других команд *nix (NetBSD, OpenBSD, Linux, ...) заинтересуется в совместной работе над стандартным набором расширений DocBook, пожалуйста, свяжитесь с Группа Менеджеров Дерева Документации FreeBSD .

Расширений FreeBSD (на данный момент) нет в коллекции портов. Они хранятся в дереве CVS FreeBSD как doc/share/sgml/freebsd.dtd.


4.2.2. Формальный Публичный Идентификатор (Formal Public Identifier - FPI)

В соответствии с рекомендациями DocBook по написанию FPI для собственный настроек DocBook, FPI расширенного DocBook DTD для FreeBSD такова;

PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN"

4.2.3. Структура документа

DocBook позволяет вам структурировать документ несколькими способами. В Проекте Документирования FreeBSD мы используем два основных типа документа DocBook: книга (book) и статья (article).

Книга организуется в виде глав (<chapter>). Это обязательное условие. Между книгой и главой могут быть части (<part>) для того, чтобы дать дополнительный уровень организации. Руководство организовано именно так.

Глава может содержать (или может не содержать) один или большее количество разделов. Это выделяется элементом <sect1>. Если раздел содержит другой подраздел, то используются элемент <sect2> и так далее, до <sect5>.

В главах и разделах содержится оставшийся текст.

Статья устроена проще, чем книга, в ней не используются главы. Вместо них содержимое статьи организуется в один или большее количество разделов, с использованием те же самые элементы <sect1> (<sect2> и так далее), что используются в книгах.

Очевидно, что вы должны следовать характеру документа, который вы создаете, для решения того, лучше размечать его как книгу или как статью. Статьи хорошо подходят для информации, которую не нужно разбивать дальше на несколько глав, и которая имеет относительно небольшой объем, до 20-25 страниц текста. Книги лучше подходят для информации, которая может разбиваться на несколько глав, возможно, с примечаниями и тому подобным содержимым.

Все учебники FreeBSD размечены как статьи, FAQ по FreeBSD и Руководство по FreeBSD размечены как книги.


4.2.3.1. Начало книги

Текст книги размещается внутри элемента <book>. Этот элемент, наряду с тем, что содержит структурированную разметку, может содержать элементы, которые включают дополнительную информацию о книге. Это либо мета-информация, используемая для справочных целей, либо дополнительный текст, используемый для генерации заглавной страницы.

Эта дополнительная информация должна располагаться в <bookinfo>.

Пример 4-21. Заготовка для <book> с <bookinfo>

<book>
  <bookinfo>
    <title>Здесь ваш заголовок</title>

    <author>
      <firstname>Ваше имя</firstname>
      <surname>Ваша фамилия</surname>
      <affiliation>
    <address><email>Ваш адрес электронной почты</email></address>
      </affiliation>
    </author>

    <copyright>
      <year>1998</year>
      <holder role="mailto:Ваш e-mail">Ваше имя</holder>
    </copyright>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>Сюда включите обзор содержимого книги.</para>
    </abstract>
  </bookinfo>

  ...

</book>

4.2.3.2. Начало статьи

Содержимое статьи размещается внутри элемента <article>. Этот элемент, наряду с тем, что содержит структурированную разметку, может содержать элементы, которые включают дополнительную информацию о статье. Это либо мета-информация, используемая для справочных целей, либо дополнительный текст, используемый для генерации заглавной страницы.

Эта дополнительная информация должна размещаться внутри <articleinfo>.

Пример 4-22. Заготовка <article> с <articleinfo>

<article>
  <articleinfo>
    <title>Здесь ваш заголовок</title>

    <author>
      <firstname>Ваше имя</firstname>
      <surname>Ваша фамилия</surname>
      <affiliation>
    <address><email>Ваш e-mail</email></address>
      </affiliation>
    </author>

    <copyright>
      <year>1998</year>
      <holder role="mailto:Ваш e-mail">Ваше имя</holder>
    </copyright>

    <releaseinfo>$FreeBSD$</releaseinfo>

    <abstract>
      <para>Сюда включите обзор содержимого статьи.</para>
    </abstract>
  </articleinfo>

  ...

</article>

4.2.3.3. Оформление глав

Используйте <chapter> для разметки ваших глав. Каждая глава имеет обязательный элемент <title>. Статьи не содержат глав, они используются только в книгах.

Пример 4-23. Простая глава

<chapter>
  <title>Заголовок главы</title>

  ...
</chapter>

Глава не может быть пустой; она должна содержать элементы, кроме <title>. Если вы хотите включить пустую главу, то воспользуйтесь пустым параграфом.

Пример 4-24. Пустые главы

<chapter>
  <title>Это пустая глава</title>

  <para></para>
</chapter>

4.2.3.4. Секции ниже глав

В книгах главы могут (но но обязаны) разбиваться на разделы, подразделы и так далее. В статьях разделы являются главными структурными элементами, и каждая статья должна содержать по крайней мере один раздел. Используйте элемент <sectn>. n задает номер раздела, определяющий его уровень вложенности.

Первый раздел <sectn> это <sect1>. В главе вы можете иметь один или большее количество таких разделов. Они могут содержать один или большее количество элементов <sect2> и так далее, вплоть до <sect5>.

Пример 4-25. Разделы в главах

<chapter>
  <title>Примерная глава</title>

  <para>Некоторый текст в главе.</para>

  <sect1>
    <title>Первый раздел (1.1)</title>

    ...
  </sect1>

  <sect1>
    <title>Второй раздел (1.2)</title>

    <sect2>
      <title>Первый подраздел (1.2.1)</title>

      <sect3>
    <title>Второй подподраздел (1.2.1.1)</title>

    ...
      </sect3>
    </sect2>

    <sect2>
      <title>Второй подраздел (1.2.2)</title>

      ...
    </sect2>
  </sect1>
</chapter>

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


4.2.3.5. Разбиение при помощи <part>

Вы можете создать еще один уровень организации между <book> и <chapter> при помощи одного или большего количества элементов <part>. Этого нельзя сделать в <article>.

<part>
  <title>Введение</title>

  <chapter>
    <title>Обзор</title>

    ...
  </chapter>

  <chapter>
    <title>Что такое FreeBSD?</title>

    ...
  </chapter>

  <chapter>
    <title>История</title>

    ...
  </chapter>
</part>

4.2.4. Блочные элементы

4.2.4.1. Параграфы

DocBook поддерживает три типа параграфов: <formalpara>, <para> и <simpara>.

В большинстве случаев вам потребуется использовать только <para>. <formalpara> включает элемент <title>, а <simpara> запрещает использование некоторых элементов из <para>. Остановите свой выбор на <para>.

Пример 4-26. <para>

Использование:

<para>Это параграф.  Он может содержать
  практически любой другой элемент.</para>

Результат обработки:

Это параграф. Он может содержать практически любой другой элемент.


4.2.4.2. Блочное цитирование

Блочное цитирование является расширенным цитированием из другого документа, который не может быть включен в текущий параграф. Вам это будет требоваться нечасто.

Блочные цитаты могут опционально содержать заголовок и атрибуты (или могут остаться без заголовка и без атрибутов).

Пример 4-27. <blockquote>

Использование:

<para>Короткий отрывок из Конституции США;</para>

<blockquote>
  <title>Preamble to the Constitution of the United States</title>

  <attribution>Copied from a web site somewhere</attribution>
    
  <para>We the People of the United States, in Order to form a more perfect
    Union, establish Justice, insure domestic Tranquility, provide for the
    common defence, promote the general Welfare, and secure the Blessings
    of Liberty to ourselves and our Posterity, do ordain and establish this
    Constitution for the United States of America.</para>
</blockquote>

Выводимый результат:

 

Preamble to the Constitution of the United States

We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.

 
--Copied from a web site somewhere  

4.2.4.3. Советы, замечания, предупреждения, предостережения, важная информация и заметки на полях.

Вам может потребоваться включить дополнительную информацию отдельно от основного текста. Обычно это ''мета''-информация, которую должен принять во внимание пользователь.

В зависимости от природы информации, должен использоваться элемент <tip>, <note>, <warning>, <caution> или <important>. Либо, если информация связана с основным текстом, но не является чем-либо из перечисленного, используйте элемент <sidebar>.

Условия, при которых должен выбираться конкретный тип элемента, размыты и четко не формулируются. Документация по DocBook предлагает следующее;

  • Note (замечание) для информации, на которую должны обратить внимание все читатели.

  • Элемент Important (важное) является разновидностью элемента Note.

  • Caution (предостережение) для информации относительно возможных потерь данных или порчи программного обеспечения.

  • Warning (предупреждение) для информации, касающейся возможной порчи оборудования или нанесения вреда жизни или органам.

Пример 4-28. <warning>

Использование:

<warning>
  <para>Установка FreeBSD может привести к желанию удалить Windows с вашего
    винчестера.</para>
</warning>

Внимание: Установка FreeBSD может привести к желанию удалить Windows с вашего винчестера.


4.2.4.4. Списки и процедуры

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

Для этого используйте элементы <itemizedlist>, <orderedlist> или <procedure> [4]

<itemizedlist> и <orderedlist> похожи на соответствующие элементы из HTML, <ul> и <ol>. Каждый из них состоит из одного или большего количества элементов <listitem>, и каждый <listitem> содержит один или большее количество блочных элементов. Элементы <listitem> аналогичны меткам <li> из HTML. Однако, в отличие от HTML, они обязательны.

<procedure> несколько от них отличается. Он состоит из элементов <step> (шаг), которые, в свою очередь, состоят из дополнительных элементов <step> или <substep>. Каждый элемент <step> содержит блочные элементы.

Пример 4-29. <itemizedlist>, <orderedlist> и <procedure>

Использование:

<itemizedlist>
  <listitem>
    <para>Это первый списочный элемент.</para>
  </listitem>

  <listitem>
    <para>Это второй списочный элемент.</para>
  </listitem>
</itemizedlist>

<orderedlist>
  <listitem>
    <para>Это первый упорядоченный элемент.</para>
  </listitem>

  <listitem>
    <para>Это второй упорядоченный элемент.</para>
  </listitem>
</orderedlist>

<procedure>
  <step>
    <para>Сделайте это.</para>
  </step>

  <step>
    <para>Затем сделайте то.</para>
  </step>

  <step>
    <para>А теперь сделайте вот так.</para>
  </step>
</procedure>

Получаемый результат:

  • Это первый списочный элемент.

  • Это второй списочный элемент.

  1. Это первый упорядоченный элемент.

  2. Это второй упорядоченный элемент.

  1. Сделайте это.

  2. Затем сделайте то.

  3. А теперь сделайте вот так.


4.2.4.5. Показ примеров файлов

Если вы хотите показать пользователю фрагмент файла (или, возможно, файл полностью), поместите его в элемент <programlisting>.

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

Пример 4-30. <programlisting>

Использование:

<para>Когда вы закончите, ваша программа должна
  иметь примерно такой вид:</para>

<programlisting>#include &lt;stdio.h&gt;

int
main(void)
{
    printf("hello, world\n");
}</programlisting>

Отметьте, что угловые скобки в строке #include нужно описывать по их соответствующим сущностям, а не напрямую.

Результат выдачи:

Когда вы закончите, ваша программа должна иметь примерно такой вид;

#include <stdio.h>

int
main(void)
{
    printf("hello, world\n");
}

4.2.4.6. Отсылки

Отсылка является механизмом для ссылки на часть текста, которая встретилась ранее, или в определенной позицию внутри ранее идущего примера, без ссылки на него внутри текста.

Чтобы это сделать, пометьте интересующие области в вашем примере (<programlisting>, <literallayout> или что там у вас еще) элементом <co>. Каждый элемент должен иметь уникальный присвоенный ему идентификатор id. После примера поместите <calloutlist>, который ссылается на пример и дает дополнительный комментарий.

Пример 4-31. <co> и <calloutlist>

<para>Когда вы закончите, ваша программа
  должна иметь примерно такой вид;</para>

<programlisting>#include &lt;stdio.h&gt; <co id="co-ex-include">

int <co id="co-ex-return">
main(void)
{
    printf("hello, world\n"); <co id="co-ex-printf">
}</programlisting>

<calloutlist>
  <callout arearefs="co-ex-include">
    <para>Включение стандартного файла объявлений IO.</para>
  </callout>

  <callout arearefs="co-ex-return">
    <para>Указывает на то, что <function>main()</function> возвращает
      int.</para>
  </callout>

  <callout arearefs="co-ex-printf">
    <para>Вызов <function>printf()</function>, который выдает
      <literal>hello, world</literal> на стандартный вывод.</para>
  </callout>
</calloutlist>

Результат обработки:

Когда вы закончите, ваша программа должна иметь примерно такой вид;

#include <stdio.h> (1)

int (2)
main(void)
{
    printf("hello, world\n"); (3)
}
(1)
Включение стандартного файла объявлений IO.
(2)
Указывает на то, что main() возвращает int.
(3)
Вызов printf(), который выдает hello, world на стандартный вывод.

4.2.4.7. Таблицы

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

Вообще (обратитесь к документации по DocBook для получения дополнительной информации) таблица (которая может быть формальная или неформальная) состоит из элемента <table>. Он содержит по крайней мере один элемент <tgroup>, задающий (как атрибут) количество столбцов в этой табличной группе. Внутри табличной группы вы можете иметь один элемент <thead>, который содержит элементы для заголовков таблицы (заголовки столбцов) и один элемент <tbody>, содержащий тело таблицы.

Как <tgroup>, так и <thead> содержат элементы <row>, в свою очередь, содержащие элементы <entry>. Каждый элемент <entry> задает одну ячейку в таблице.

Пример 4-32. <informaltable>

Использование:

<informaltable frame="none" pgwide="1">
  <tgroup cols="2">
    <thead>
      <row>
    <entry>Это заголовок столбца 1</entry>
    <entry>Это заголовок столбца 2</entry>
      </row>
    </thead>

    <tbody>
      <row>
    <entry>Строка 1, столбец 1</entry>
    <entry>Строка 1, столбец 2</entry>
      </row>

      <row>
    <entry>Строка 2, столбец 1</entry>
    <entry>Строка 2, столбец 2</entry>
      </row>
    </tbody>
  </tgroup>
</informaltable>

Выдаваемый результат:

Это заголовок столбца 1 Это заголовок столбца 2
Строка 1, столбец 1 Строка 1, столбец 2
Строка 2, столбец 1 Строка 2, столбец 2

Вместе с элементом <informaltable> всегда используйте атрибут pgwide со значением 1. Если атрибут будет опущен, то из-за ошибки в в браузере Internet Explorer таблица будет отображаться некорректно.

Если вам не нужна граница вокруг таблицы, то к элементу <informaltable> может быть добавлен атрибут frame со значением none (то есть <informaltable frame="none">).

Пример 4-33. Таблицы с frame="none"

Выдаваемый результат:

Это заголовок столбца 1 Это заголовок столбца 2
Строка 1, столбец 1 Строка 1, столбец 2
Строка 2, столбец 1 Строка 2, столбец 2

4.2.4.8. Примеры, которым нужно следовать пользователю

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

При этом задействуется некоторое количество различных элементов и сущностей.

<screen>

Все, что пользователь видит в этом примере на экране компьютера, поэтому элемент и называется <screen>.

Внутри <screen>, пробелы имеют значение.

<prompt>, &prompt.root; и &prompt.user;

Часть из того, что пользователь увидит на экране, является приглашением компьютера (от ОС, командного процессора или прикладной программы. Это должно быть размечено при помощи <prompt>.

Как особый случай, для двух приглашений для обычного пользователя и для администратора даны сущности. Каждый раз, когда вы хотите указать, что пользователь работает с приглашением оболочки, используйте по необходимости &prompt.root; или &prompt.user;. Их не нужно заключать внутрь <prompt>.

Замечание: &prompt.root; и &prompt.user; являются расширениями FreeBSD для DocBook, и не являются частью исходного DTD.

<userinput>

При выводе текста, который должен набрать пользователь, заключите его в метки <userinput>. Он, скорее всего, будет выведен другим образом.

Пример 4-34. <screen>, <prompt> и <userinput>

Использование:

<screen>&prompt.user; <userinput>ls -1</userinput>
foo1
foo2
foo3
&prompt.user; <userinput>ls -1 | grep foo2</userinput>
foo2
&prompt.user; <userinput>su</userinput>
<prompt>Password: </prompt>
&prompt.root; <userinput>cat foo2</userinput>
This is the file called 'foo2'</screen>

Выводимый результат:

% ls -1
foo1
foo2
foo3
% ls -1 | grep foo2
foo2
% su
Password: 
# cat foo2
This is the file called 'foo2'

Замечание: Хотя мы выводим содержимое файла foo2, оно не размечается как <programlisting>. <programlisting> предназначен для вывода фрагментов файлов вне связи с действиями пользователя.


4.2.5. Строчные элементы

4.2.5.1. Выделение информации

Когда вы хотите выделить некоторое слово или фразу, используйте <emphasis>. Они могут быть выведены наклонным шрифтом, или жирным шрифтом, или могут проговариваться другим тоном системой преобразования текста в речь.

Внутри документа нет способа изменить способ выделения, нет эквивалентам <b> и <i> из HTML. Если информация, которую вы выделяете, важна, то используйте <important> вместо <emphasis>.

Пример 4-35. <emphasis>

Использование:

<para>FreeBSD, без сомнения, является
  <emphasis>наилучшей</emphasis> операционной Unix-подобной системой для
  архитектуры Intel.</para>

Выводимый результат:

FreeBSD, без сомнения, является наилучшей операционной Unix-подобной системой для архитектуры Intel.


4.2.5.2. Цитирование

Для того, чтоб процитировать текст из другого документа или источника, или для того чтобы выделить фигуральное выражение, используйте <quote>. В пределах тэга <quote> Вы можете использовать большинство тэгов разметки доступных для нормального текста.

Пример 4-36. Цитирование

Использование:

<para>Несмотря на это убедитесь, что поиск не выходит за
  <quote>пределы между локальным и публичным администрированием</quote>,
  как RFC 1535 описывает это.</para>

Выводимый результат:

Несмотря на это убедитесь, что поиск не выходит за ''пределы между локальным и публичным администрированием'', как RFC 1535 описывает это.


4.2.5.3. Клавиши, кнопки мыши и комбинации

Чтобы описать некоторую клавишу на клавиатуре, используйте <keycap>. Чтобы описать кнопку мыши, воспользуйтесь <mousebutton>. А чтобы описать комбинацию нажатий клавиш или щелчков мыши, заключите их в <keycombo>.

<keycombo> имеет атрибут под названием action, который может принимать одно из значений click, double-click, other, press, seq или simul. Последние два значения определяют, должны ли клавиши или кнопки нажиматься последовательно или одновременно.

Таблицы стилей автоматически добавят все необходимые связующие символы, такие, как +, между наименованиями клавиш при объединении в <keycombo>.

Пример 4-37. Клавиши, кнопки мыши и комбинации

Использование:

<para>Чтобы переключиться во второй
    виртуальный терминал, нажмите <keycombo action="simul"><keycap>Alt</keycap>
    <keycap>F1</keycap></keycombo>.</para>

<para>Чтобы выйти из редактора <command>vi</command> без сохранения вашей
  работы, наберите
  <keycombo action="seq"><keycap>Esc</keycap><keycap>:</keycap>
  <keycap>q</keycap><keycap>!</keycap></keycombo>.</para>

<para>Мой оконный менеджер настроен так, что
  <keycombo action="simul"><keycap>Alt</keycap>
    <mousebutton>right</mousebutton>
  </keycombo> кнопка мыши используется для передвижения
  окон.</para>

Выводимый результат:

Чтобы переключиться во второй виртуальный терминал, нажмите Alt+F1.

Чтобы выйти из редактора vi без сохранения вашей работы, наберите Esc : q !.

Мой оконный менеджер настроен так, что Alt+right кнопка мыши используется для передвижения окон.


4.2.5.4. Прикладные программы, команды, параметры и цитаты

Вам часто будет требоваться описать как прикладные программы, так и команды при написании для Руководства. Разница между ними проста: приложение является названием набора (или, возможно, всего лишь 1) программ, которые выполняют конкретную задачу. Команда является названием программы, которую может запустить пользователь.

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

Наконец, вам часто будет нужно указывать команду с номером раздела ее справочной страницы, в формате ''команда(номер)'', обычном для справочной системы Unix.

Выделяйте имена приложений при помощи <application>.

Когда вы хотите указать команду вместе с разделом ее справочной страницы (что бывает в большинстве случаев), то элемент DocBook называется <citerefentry>. Он будет содержать два элемента, <refentrytitle> и <manvolnum>. Содержимым <refentrytitle> является имя команды, а в <manvolnum> помещается номер раздела справочной страницы.

Это может оказаться громоздким при написании, поэтому для облегчения этой задачи был создан набор сущностей общего назначения. Каждая сущность имеет форму &man.manual-page.manual-section;.

Файлом, в котором содержатся эти сущности, является doc/share/sgml/man-refs.ent, и к нему можно обратиться посредством следующего FPI:

PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN"

Таким образом, начало вашей документации, скорее всего, будет выглядеть примерно так:

<!DOCTYPE book PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [

<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
%man;

...

]>

Используйте <command>, когда вы хотите включить название команды ''в строку'', но она должна выглядеть так, как будто её должен набрать пользователь.

Для разметки параметров, которые передаются описываемой команде, используйте <option>.

Когда Вы ссылаетесь к одной команде несколько раз в течение короткого периода времени, то предпочтительно использовать нотацию вида &man.command.sec tion; для разметки первой ссылки и <command> для последующих ссылок. Это делает результат, особенно HTML, гораздо симпатичнее на вид.

Это может запутать, и иногда выбор не всегда очевиден. Надеемся, этот пример сделает это более понятным.

Пример 4-38. Приложения, команды и параметры.

Использование:

<para><application>Sendmail</application>
  является наиболее часто используемым почтовым приложением Unix.</para>

<para><application>Sendmail</application> включает программы
  <citerefentry>
    <refentrytitle>sendmail</refentrytitle>
    <manvolnum>8</manvolnum>
  </citerefentry>, &man.mailq.8; и &man.newaliases.8;.</para>

<para>Один из параметров командной строки для
  <citerefentry>
    <refentrytitle>sendmail</refentrytitle>
    <manvolnum>8</manvolnum>
  </citerefentry>, <option>-bp</option>, будет выводить текущее состояние
  сообщений в почтовой очереди.  Проверьте это, запустив из командной строки
  <command>sendmail -bp</command>.</para>

Выводимый результат:

Sendmail является наиболее часто используемым почтовым приложением Unix.

Sendmail включает программы sendmail(8), mailq(8) и newaliases(8).

Один из параметров командной строки для sendmail(8), -bp, будет выводить текущее состояние сообщений в почтовой очереди. Проверьте это, запустив из командной строки sendmail -bp.

Замечание: Заметьте, насколько легче использовать нотацию &man.command.section;.


4.2.5.5. Файлы, каталоги, расширения

Хотите ли вы указать имя файла, каталог или расширение файла, используйте <filename>.

Пример 4-39. <filename>

Использование:

<para>Исходный код SGML для Руководства на
  английском языке можно найти в каталоге
  <filename>/usr/doc/en/handbook/</filename>.  В этом каталоге первый файл
  называется <filename>handbook.sgml</filename>.  Вы также должны посмотреть на
  <filename>Makefile</filename> и некоторое количество файлов с расширением
  <filename>.ent</filename>.</para>

Выводимый результат:

Исходный код SGML для Руководства на английском языке можно найти в каталоге /usr/doc/en/handbook/. В этом каталоге первый файл называется handbook.sgml. Вы также должны посмотреть на Makefile и некоторое количество файлов с расширением .ent.


4.2.5.6. Названия портов

Расширение FreeBSD: Эти элементы являются частями расширения FreeBSD к DocBook, и их нет в исходном DocBook DTD.

Вам может потребоваться включить в документацию имя программы из Коллекции Портов FreeBSD. Используйте для этого метку <filename> с атрибутом role. Так как порты могут быть установлены в любое место, включайте только категорию и название порта; не включайте сюда /usr/ports.

Пример 4-40. <filename> с атрибутом role

Использование:

<para>Установите <filename role="package">net/ethereal</filename> для просмотра сетевого трафика.</para>

Выводимый результат:

Установите net/ethereal для просмотра сетевого трафика.


4.2.5.7. Устройства

Расширение FreeBSD: Эти элементы являются частью расширения FreeBSD к DocBook, и их их нет в исходном DocBook DTD.

При указания устройства у вас есть два варианта. Вы можете либо указать устройство в том виде, как оно находится в /dev, или вы можете использовать имя устройства так, как оно появляется в ядре. В последнем случае используйте <devicename>.

Иногда у вас нет выбора. Некоторые устройства, такие, как сетевые адаптеры, не имеют соответствий в /dev, или они значительно отличаются от вышеупомянутых.

Пример 4-41. <devicename>

Использование:

<para><devicename>sio</devicename> используется
  для коммуникаций по последовательным каналам по FreeBSD.
  <devicename>sio</devicename> доступно через несколько файлов устройств из
  <filename>/dev</filename>, включая <filename>/dev/ttyd0</filename>
  и <filename>/dev/cuaa0</filename>.</para>

<para>В отличие от него, сетевые устройства, такие, как
  <devicename>ed0</devicename>, не присутствуют в <filename>/dev</filename>.</para>

<para>В MS-DOS первый дисковод обозначается как
  <devicename>a:</devicename>.  Во FreeBSD это
  <filename>/dev/fd0</filename>.</para>

Выводимый результат:

sio используется для коммуникаций по последовательным каналам по FreeBSD. sio доступно через несколько файлов устройств из /dev, включая /dev/ttyd0 и /dev/cuaa0.

В отличие от него, сетевые устройства, такие, как ed0, не присутствуют в /dev.

В MS-DOS первый дисковод обозначается как a:. Во FreeBSD это /dev/fd0.


4.2.5.8. Хосты, домены, адреса IP и так далее

Расширение FreeBSD: Эти элементы являются частями расширения FreeBSD к DocBook, и их нет в исходном DocBook DTD.

Вы можете разметить идентификационную информацию для компьютеров, работающих в сети (хостов) несколькими способами, в зависимости от природы информации. Во всех случаях используется элемент </hostid> с атрибутом role, задающим тип размечаемой информации.

Без ролевого атрибута или role="hostname"

Без ролевого атрибута (то есть <hostid>...<hostid> размечаемая информация представляет собой просто имя хоста, такое, как freefall или wcarchive. Вы можете явно задать его при помощи role="hostname".

role="domainname"

Текст является именем домена, таким, как FreeBSD.org или ngo.org.uk. Компонент с именем хоста здесь отсутствует.

role="fqdn"

Текст является Полным Доменным Именем, с доменной и хостовой частями.

role="ipaddr"

Текст является адресом IP, чаще всего записанном в виде четверки чисел через точку.

role="ip6addr"

Текст является адресом IPv6.

role="netmask"

Текст является сетевой маской, которая может быть записана как четверка чисел через точку, в виде шестнадцатеричной строки или как /, за которым следует число.

role="mac"

Текст является MAC-адресом Ethernet, записанном в виде последовательности 2-символьных шестнадцатеричных чисел, разделенных двоеточиями.

Пример 4-42. <hostid> и роли

Использование:

<para>Собственно машину всегда можно
  обозначить по имени <hostid>localhost</hostid> с IP-адресом <hostid
  role="ipaddr">127.0.0.1</hostid>.</para>

<para>Домен <hostid role="domainname">FreeBSD.org</hostid> содержит несколько
  различных хостов, включая <hostid role="fqdn">freefall.FreeBSD.org</hostid>
  и <hostid role="fqdn">bento.FreeBSD.org</hostid>.</para>

<para>При добавлении алиаса IP к интерфейсу (при помощи
  <command>ifconfig</command>) <emphasis>всегда</emphasis> используйте сетевую
  маску <hostid role="netmask">255.255.255.255</hostid> (что может быть
  записано также как <hostid
  role="netmask">0xffffffff</hostid>.</para>

<para>MAC-адрес однозначно идентифицирует любую существующий сетевой адаптер.
  Типичный MAC-адрес выглядит как <hostid
  role="mac">08:00:20:87:ef:d0</hostid>.</para>

Выводимый результат:

Собственно машину всегда можно обозначить по имени localhost с IP-адресом 127.0.0.1.

Домен FreeBSD.org содержит несколько различных хостов, включая freefall.FreeBSD.org и bento.FreeBSD.org.

При добавлении алиаса IP к интерфейсу (при помощи ifconfig) всегда используйте сетевую маску 255.255.255.255 (что может быть записано также как 0xffffffff.

MAC-адрес однозначно идентифицирует любую существующий сетевой адаптер. Типичный MAC-адрес выглядит как 08:00:20:87:ef:d0.


4.2.5.9. Имена пользователей

Расширение FreeBSD: Эти элементы являются частями расширения FreeBSD к DocBook, и их нет в исходном DocBook DTD.

Когда вам нужно указать некоторое имя пользователя, такое, как root или bin, используйте <username>.

Пример 4-43. <username>

Использование:

<para>Для выполнения большинства функций
  системного администрирования вам нужно быть пользователем
  <username>root</username>.</para>

Выводимый результат:

Для выполнения большинства функций системного администрирования вам нужно быть пользователем root.


4.2.5.10. Описание Makefiles

Расширение FreeBSD: Эти элементы являются частями расширения FreeBSD к DocBook, и их нет в исходном DocBook DTD.

Для описания частей файлов Makefile имеются два элемента, <maketarget> и <makevar>.

<maketarget> идентифицирует цель для построения, экспортируемую из Makefile, которая может быть задана в качестве параметра для make. <makevar> идентифицирует переменную, которая может быть задана (в окружении, в командной строке make или внутри Makefile) для изменения процесса построения.

Пример 4-44. <maketarget> и <makevar>

Использование:

<para>Двумя распространенными целями в
  <filename>Makefile</filename> являются <maketarget>all</maketarget> и
  <maketarget>clean</maketarget>.</para>

<para>Обычно вызов <maketarget>all</maketarget> приводит к перестроению
  приложения, а вызов <maketarget>clean</maketarget> удаляет временные файлы
  (к примеру, <filename>.o</filename>), созданные в процессе построения.</para>

<para><maketarget>clean</maketarget> может контролироваться несколькими
  переменными, среди которых <makevar>CLOBBER</makevar> и
  <makevar>RECURSE</makevar>.</para>

Выводимый результат:

Двумя распространенными целями в Makefile являются all и clean.

Обычно вызов all приводит к перестроению приложения, а вызов clean удаляет временные файлы (к примеру, .o), созданные в процессе построения.

clean может контролироваться несколькими переменными, среди которых CLOBBER и RECURSE.


4.2.5.11. Дословный текст

Часто вам будет нужно включить в Руководство ''дословный'' текст. Это текст, который взят из другого файла, или который должен быть скопирован из Руководства в другой файл без изменений.

Иногда для разметки такого текста будет достаточно <programlisting>. <programlisting> не всегда подходит, в частности, когда вы хотите включить часть файла ''внутрь'' параграфа.

В таких случаях используйте <literal>.

Пример 4-45. <literal>

Использование:

<para>Строка <literal>maxusers
  10</literal> в файле конфигурации ядра определяет размер многих системных
  таблиц, и примерно задает количество одновременных входов, которые может
  поддерживать система.</para>

Выводимый результат:

Строка maxusers 10 в файле конфигурации ядра определяет размер многих системных таблиц, и примерно задает количество одновременных входов, которые может поддерживать система.


4.2.5.12. Выделение пунктов, которые пользователь должен заполнить

Часто бывает, что вам нужно показать пользователю, что нужно сделать, или сослаться на файл, или на команду, или на что-то подобное, когда пользователь не может просто скопировать даваемые примеры, а должен вместо этого включить какую-то информацию от себя.

На этот случай был разработан элемент <replaceable>. Используйте его внутри других элементов для выделения частей содержимого этих элементов, которые должен заменить пользователь.

Пример 4-46. <replaceable>

Использование:

<informalexample>
  <screen>&prompt.user; <userinput>man <replaceable>команда</replaceable></userinput></screen>
</informalexample>

Выводимый результат:

% man команда

<replaceable> может быть использован во многих различных элементах, включая <literal>. Этот пример также показывает, что <replaceable> должен окружать только то содержимое, которое пользователь должен заменить. Все остальное изменять не нужно.

Использование:

<para>Строка <literal>maxusers <replaceable>n</replaceable></literal>
  в файле конфигурации ядра определяет размер многих системных таблиц, и
  примерно задает количество одновременных входов, которое поддерживает
  система.</para>

<para>Для настольной рабочей станции в качестве <replaceable>n</replaceable>
  подойдет значение <literal>32</literal>.</para>

Выводимый результат:

Строка maxusers n в файле конфигурации ядра определяет размер многих системных таблиц, и примерно задает количество одновременных входов, которое поддерживает система.

Для настольной рабочей станции в качестве n подойдет значение 32.


4.2.5.13. Цитирование системных сообщений об ошибках

Вам может понадобиться показать ошибки, генерируемые FreeBSD. Выделяйте их при помощи <errorname>. Этот элемент отмечает в точности сообщение об ошибке.

Пример 4-47. <errorname>

Использование:

<screen><errorname>Panic: cannot mount root</errorname></screen>

Выводимый результат:

Panic: cannot mount root

4.2.6. Изображения

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

Вам также потребуется установить порт graphics/ImageMagick, который используется для преобразований между различными графическими форматами. Это большой порт, и основной его объем не нужен. Однако, пока мы работаем над файлами Makefile и другой инфраструктурой, проще всего использовать его. Этот порт не входит в мета-порт textproc/docproj, вы должны установить его вручную.

Лучшим примером того, чему нужно следовать на практике, является документ doc/en_US.ISO8859-1/articles/vm-design/. Если вам будут не совсем понятны последующие объяснения, взгляните на файлы в этом каталоге, чтобы посмотреть, как все это работает вместе. Поэкспериментируйте с созданием версий документа с разным форматированием, чтобы посмотреть, как выводятся размеченные изображения.


4.2.6.1. Форматы изображений

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

Для изображений, которые в основном являются векторными, таких, как сетевые диаграммы, графики и тому подобное, используйте Encapsulated Postscript и проследите за тем, чтобы файлы с вашими иллюстрациями имели расширение .eps.

Для точечных изображений, таких, как снимки экранов, используйте формат Portable Network Graphic, и проследите за тем, чтобы файлы с вашими иллюстрациями имели расширение .png.

Это единственные форматы, в которых могут быть изображения, помещаемые в хранилище CVS.

Используйте подходящий формат для подходящих иллюстраций. Предполагается, что в вашей документации будет смесь изображений в форматах EPS и PNG. Файлы Makefile будут обеспечивать выбор корректного формата изображений в зависимости от выбранного вами формата выдачи документации. Не коммитьте в хранилище одно и то же изображение в двух разных форматах.

Важно: Предполагается, что Проект Документирования перейдет на использование формата SVG (Scalable Vector Graphic - масштабируемая векторная графика) для векторных изображений. Однако текущее состояние инструментов, которые могут редактировать SVG, делает этот переход непрактичным.


4.2.6.2. Разметка

Разметка для изображения сравнительно проста. Сначала разметьте <mediaobject>. <mediaobject> может содержать другие, более специфичные объекты. Мы имеем дело с двумя, <imageobject> и <textobject>.

Вы должны включить один <imageobject> и два элемента <textobject>. <imageobject> будет указывать на имя используемого файла с изображением (без расширения). Элементы <textobject> содержат информацию, которая будет выдаваться пользователю вместе или вместо изображения.

Есть два условия, где это может быть.

  • Когда читатель смотрит документацию в HTML. В этом случае каждому изображению нужно будет поставить в соответствие альтернативный текст для показа пользователю, обычно во время загрузки изображения, или при наведении курсора мыши на изображение.

  • Когда читатель смотрит документацию в формате обычного текста. В этом случае каждая иллюстрация должна иметь эквивалент в псевдографике ASCII для выдачи пользователю.

Наверное, пример поможет облегчить понимание этого. Предположим, что у вас есть файл изображения с именем fig1, которое вы хотите включить в документ. Эта иллюстрация представляет собой прямоугольник с буквой A внутри. Разметка для этого случая будет такова.

<mediaobject>
  <imageobject>
    <imagedata fileref="fig1"> (1)
  </imageobject>

  <textobject>
    <literallayout class="monospaced">+---------------+ (2)
|       A       |
+---------------+</literallayout>
  </textobject>

  <textobject>
    <phrase>Рисунок</phrase> (3)
  </textobject>
</mediaobject>
(1)
Помещение элемента <imagedata> внутрь элемента <imageobject>. Атрибут fileref должен содержать имя файла включаемого изображения, без расширения. Таблицы стилей автоматически определят, какое расширение должно быть добавлено к имени файла.
(2)
Первый <textobject> должен содержать элемент <literallayout>, в котором атрибут class задан как monospaced. Это ваша возможность продемонстрировать свое мастерство в создании изображений в ASCII. Это содержимое будет использоваться, если документ будет преобразовываться в формат обычного текста.

Отметьте, что первая и последняя строки содержимого элемента <literallayout> располагаются впритык к меткам элемента. Это избавляет от включения дополнительных пробелов.

(3)
Второй <textobject> должен содержать единственный элемент <phrase>. Его содержимое станет атрибутом alt для изображения при преобразовании документа в формат HTML.

4.2.6.3. Строки в Makefile

Ваши иллюстрации должны быть перечислены в Makefile в переменной IMAGES. Эта переменная должна содержать имя всех ваших исходных изображений. К примеру, если вы создали три рисунка, fig1.eps, fig2.png и fig3.png, то в вашем Makefile должны быть строки, подобные следующим.

...
IMAGES= fig1.eps fig2.png fig3.png
...

или же

...
IMAGES=  fig1.eps
IMAGES+= fig2.png
IMAGES+= fig3.png
...

И снова Makefile сам составит полный список иллюстраций, которые нужны для построения вашего документа, вам нужно только перечислить файлы с изображениями, которые дали вы.


4.2.6.4. Изображения и главы в подкаталогах

Вы должны быть аккуратны при разбиении вашей документации на файлы меньшего размера (посмотрите Разд. 3.7.1), которые находятся в различных каталогах.

Предположим, что у вас есть книга с тремя главами, причем главы хранятся в своих собственных каталогах, с именами chapter1/chapter.sgml, chapter2/chapter.sgml и chapter3/chapter.sgml. Если в каждой главе есть изображения, связанные с ней, я рекомендую разместить эти иллюстрации в подкаталоге соответствующей главы (chapter1/, chapter2/ и chapter3/).

Однако если вы сделаете так, то должны указать имена каталогов в переменной IMAGES из Makefile и должны указать имя каталога в элементе <imagedata> вашего документа.

Например, если у вас есть chapter1/fig1.png, то chapter1/chapter.sgml должен содержать

<mediaobject>
  <imageobject>
    <imagedata fileref="chapter1/fig1"> (1)
  </imageobject>

  ...

</mediaobject>
(1)
Имя каталога должно быть указано в атрибуте fileref

Makefile должен содержать

...
IMAGES=  chapter1/fig1.png
...

Теперь все должно работать.


4.2.7. Ссылки

Замечание: Ссылки также являются строчными элементами.


4.2.7.1. Отсылки на другие части того же самого документа

Ссылки внутри того же самого документа требуют указания того, откуда вы ссылаетесь (то есть текст, на котором пользователь будет щелкать или каким-то другим способом выделять, в качестве начала связи) и того, куда вы ссылаетесь (конец связи).

Каждый элемент в DocBook имеет атрибут под названием id. Вы можете разместить текст в этом атрибуте для уникального именования элемента, которому он принадлежит.

Это значение используется, когда вы задаете источник ссылки.

Как правило, вы будете ссылаться на главы или разделы, так что добавляйте атрибут id к этим элементам.

Пример 4-48. id в главах и разделах

<chapter id="chapter1">
  <title>Введение</title>

  <para>Это введение.  Оно содержит подраздел, который идентифицируется.</para>

  <sect1 id="chapter1-sect1">
    <title>Подраздел 1</title>

    <para>Это подраздел.</para>
  </sect1>
</chapter>

Очевидно, что вы должны использовать значения, говорящие сами за себя. В пределах документа (то есть не только одного файла, но и всех составляющих его файлов) значения должны быть уникальными. Заметьте, что id для подраздела строится путем добавления текста к id главы. Это помогает обеспечить их уникальность.

Если вы хотите позволить пользователю переходить на конкретный участок документа (возможно, в середине параграфа или примера), то используйте <anchor>. В этом элементе нет содержимого, но может быть атрибут id.

Пример 4-49. <anchor>

<para>В этом параграфе имеется встроенная
  <anchor id="para1">ссылка на него.  Она не будет показываться в
  документе.</para>

Когда вы хотите предоставить пользователю ссылку, которую можно активировать (чаще всего щелчком) для перехода к разделу документа, имеющему атрибут id, вы можете использовать <xref> либо <link>.

Оба этих элемента имеют атрибут linkend. Значением этого атрибута должно быть значение, которое вы использовали в атрибуте id (не имеет значения, появлялось ли это значение раньше; это работает как для ранее объявленных, так и объявляемых позже ссылок).

Если вы используете <xref>, то вы не управляете текстом ссылки. Он будет для вас сгенерирован.

Пример 4-50. Использование <xref>

Положим, что этот фрагмент появился где-то в документе, который включает пример с id;

<para>Дополнительная информация может
  быть найдена в <xref linkend="chapter1">.</para>

<para>Более конкретная информация находится в
  <xref linkend="chapter1-sect1">.</para>

Текст ссылки будет сгенерирован автоматически, и будет выглядеть как (выделенный текст, который будет ссылкой);

Дополнительная информация может быть найдена в Глава Один.

Более конкретная информация находится в разделе с названием Подраздел 1.

Заметьте, что текст ссылки берется из названия раздела или номера главы.

Замечание: Это значит, что вы не можете использовать <xref> для отсылки на атрибут id элемента <anchor>. Элемент <anchor> не имеет содержимого, так что <xref> не сможет сгенерировать текст для ссылки.

Если вы хотите управлять текстом ссылки, то используйте <link>. В этот элемент помещается содержимое, которое будет использоваться для ссылки.

Пример 4-51. Использование <link>

Предположим, что этот фрагмент появляется где-то в документе, который включает в себя пример с id.

<para>Дополнительная информация может быть
  найдена в <link linkend="chapter1">первой главе</link>.</para>

<para>Более конкретная информация находится в <link
  linkend="chapter1-sect1">этом</link> разделе.</para>

Это приведет к генерации следующего (выделенного текста, который отмечает текст, являющийся ссылкой);

Дополнительная информация может быть найдена в первой главе.

Более конкретная информация находится в этом разделе.

Замечание: Последний пример плох. Никогда не используйте слова типа ''этот'' или ''здесь'' в качестве источника ссылки. Читателю потребуется изучать окружающий текст, чтобы выяснить, куда собственно привела ссылка.

Замечание: Вы можете использовать <link> для включения ссылки на id в элементе <anchor>, так как содержимое <link> задает текст, используемый для ссылки.


4.2.7.2. Ссылки на документы в WWW

Отсылки на внешние документы гораздо проще, если вы знаете URL документа, на который хотите сослаться. Используйте <ulink>. Атрибут url представляет собой URL страницы, на которую указывает ссылка, а содержимым элемента является текст, выдаваемый пользователю для активации ссылки.

Пример 4-52. <ulink>

Использование:

<para>Конечно, вы можете прекратить чтение
  этого документа и перейти на <ulink url="&url.base;/ru/index.html">домашнюю
  страницу FreeBSD</ulink>.</para>

Выводимый результат:

Конечно, вы можете прекратить чтение этого документа и перейти на домашнюю страницу FreeBSD.


Глава 5. * Таблицы стилей

SGML не определяет того, как документ должен выводиться для пользователя или то, как он должен выглядеть на бумаге. Для этого были разработаны различные языки для описания таблиц стилей, включая DynaText, Panorama, SPICE, JSSS, FOSI, CSS, и DSSSL.

В случае DocBook мы используем таблицы стилей, написанные на DSSSL. Для HTML мы используем CSS.


5.1. * DSSSL

Проект Документирования использует несколько адаптированную версию модульных таблиц стилей DocBook от Нома Уолша (Norm Walsh).

Они могут быть найдены в textproc/dsssl-docbook-modular.

Модифицированные таблицы стилей не включены в систему портов. Вместо этого они являются частью хранилища текстов Проекта Документирования и могут быть найдены в doc/share/sgml/freebsd.dsl. Они хорошо откомментированы, и для продолжения изучения этого раздела приглашаем вас отыскать этот файл и посмотреть, как некоторые доступные в стандартных таблицах стилей параметры были настроены для модификации вывода в Проекте Документирования FreeBSD. Этот файл также содержит примеры, показывающие, как расширять элементы, которые воспринимаются в таблицах стилей, ведь именно так форматировались элементы, специфичные для FreeBSD.


5.2. CSS

Каскадируемые таблицы стилей (Cascacding Stylesheets - CSS) представляют собой механизм для подключения информации о стиле (шрифт, толщина, размер, цвет и так далее) к элементам в документе HTML без привлечения методов собственно HTML.


5.2.1. Веб-сайт (документы HTML)

Веб-сервер FreeBSD на данный момент не использует CSS. К сожалению, внешний вид создается при помощи собственных механизмов HTML различного уровня сложности. Это должно быть исправлено, и было бы хорошим проектом для кого-нибудь, хотящего участвовать в проекте документирования.


5.2.2. Документы DocBook

Таблицы стилей DSSSL во FreeBSD включают ссылки на таблицу стилей docbook.css, о которой предполагается, что она находится в том же самом каталоге, что и файлы HTML. Файл CSS проекта копируется из doc/share/misc/docbook.css, когда документы преобразуются в HTML, и устанавливается автоматически.


Глава 6. Структурирование документов в doc/

Дерево doc/ организовано определенным образом, и документы, являющиеся частью FDP, в свою очередь, организованы определенным образом. При этом преследуется цель упрощения добавления новой документации в дерево, а также:

  1. облегчение автоматизации преобразования документов в другие форматы

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

  3. облегчить решение того, куда поместить новую документацию

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


6.1. Самый верхний уровень, doc/

имеется два типа каталогов под doc/, каждый с очень специфичными именами каталогов и значениями.

Каталог: share/

Значение: Содержит файлы, которые не являются специфичными для различных переводов и кодировок документации. Содержит подкаталоги для дальнейшей категоризации информации. К примеру, файлы, которые составляют инфраструктуру make(1), располагаются в share/mk, когда как дополнительные файлы поддержки SGML (например, расширенный DocBook DTD для FreeBSD), находятся в share/sgml.

Каталог: lang.encoding/

Значение: Для каждого имеющегося перевода и кодировки документации имеется каталог, например, en_US.ISO8859-1/ и zh_TW.Big5/. Имена длинные, но полным заданием языка и кодировки мы избавляемся от головной боли в будущем, если команда переводчиков задумает дать документацию на одном языке, но более чем в одной кодировке. Это также полностью изолирует нас от каких-либо проблем, могущим возникнуть при переходе на Unicode.


6.2. Каталоги lang.encoding/

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

Каталог: articles

Содержимое: Документация, размеченная как <article> (статья) (или ее эквивалент) в формате DocBook. Относительно короткая и разбитая на разделы. Обычно доступна только как один файл HTML.

Каталог: books

Содержимое: Документация, размеченная как <book> (книга) (или ее эквивалент) в формате DocBook. Книга имеет большой размер и делится на главы. Обычно доступна как в виде одного большого файла HTML (для тех, кто имеет быстрое подключение или хочет печатать прямо из браузера), так и в виде набора небольших связанных файлов.

Каталог: man

Содержимое: Для переводов системных страниц справочной системы. Этот каталог будет содержать одну или более каталогов mann, соответствующих переводимым разделам.

Не каждый каталог lang.encoding будет содержать все эти подкаталоги. Это зависит от того, какой объем перевода выполнила данная команда переводчиков.


6.3. Информация, специфичная для конкретных документов

Этот раздел содержит специфичные замечания о конкретных документах, управляемых FDP.


6.3.1. Руководство

books/handbook/

Руководство написано в соответствии с расширенным во FreeBSD DocBook DTD.

Руководство организовано в виде <book> (книги) DocBook. Затем она делится на части (<part>), каждая из которых может содержать несколько глав (<chapter>). Главы, в свою очередь, делятся на разделы (<sect1>) и подразделы (<sect2>, <sect3>) и так далее.


6.3.1.1. Физическая организация

В каталоге handbook расположено некоторое количество файлов и подкаталогов.

Замечание: С течением времени организация Руководства может меняться, и этот документ может отставать в описании организационных изменений. Если у вас есть вопросы по организации Руководства, пожалуйста, обратитесь в Список рассылки Проекта Документации FreeBSD.


6.3.1.1.1. Makefile

Makefile задает некоторые переменные, которые влияют на преобразование исходных текстов SGML в другие форматы, и в нем перечисляются различные исходные файлы, которые составляют Руководство. Затем в него включается стандартный файл doc.project.mk, содержащий остальной код, отвечающий собственно за преобразование одного формата в другой.


6.3.1.1.2. book.sgml

Для Руководства это документ самого верхнего уровня. Он содержит декларацию DOCTYPE для Руководства, а также элементы, описывающие его структуру.

book.sgml использует параметризованные сущности для загрузки файлов с расширением .ent. Эти файлы (описываемые далее), в свою очередь, определяют сущности общего назначения, используемые в дальнейшем во всем Руководстве.


6.3.1.1.3. directory/chapter.sgml

Каждая глава Руководства хранится в файле с именем chapter.sgml в отдельном каталоге. Каждый каталог именуется в соответствии с атрибутом id элемента <chapter>.

Например, если файл с текстом главы содержит:

<chapter id="kernelconfiguration">
...
</chapter>

то он будет называться chapter.sgml и располагаться в каталоге kernelconfiguration. В общем случае в этом файле будет содержаться полный текст главы.

При генерации версии Руководства в формате HTML получится файл kernelconfiguration.html. Это имя соответствует значению id, и не связано с названием каталога.

В ранних версиях Руководства файлы хранились в том же самом каталоге, что и book.sgml, и именовались в соответствии с атрибутом id элемента <chapter> из этого файла. Перемещение их в отдельные каталоги связано с дальнейшими планами по развитию Руководства. В частности, вскоре будет возможно включать рисунки в каждую главу. Более правильно хранить каждый рисунок в каталоге с текстом главы, чем пытаться хранить и текст, и рисунки для всех глав в одном большом каталоге. Можно будет избежать совпадений имен, и гораздо легче работать с несколькими каталогами с небольшим количеством файлов в них, чем с одним каталогом со многими файлами.

Если посмотреть, то здесь много каталогов с отдельными файлами chapter.sgml в них, включая basics/chapter.sgml, introduction/chapter.sgml и printing/chapter.sgml.

Важно: Главы и/или каталоги каталоги не обязательно должны именоваться образом, отражающим их следование в Руководстве. Их порядок может измениться при организационных изменениях внутри Руководства; такой тип реорганизации не должен (обычно) включать необходимость в переименовании файлов (если только главы не были удалены или перемещены по иерархии).

Каждый файл chapter.sgml не будет являться полным документом SGML. В частности, в них нет собственных строк DOCTYPE в начале файла.

Это не так уж хорошо, так как с ними невозможно будет работать как обычными файлами SGML и просто преобразовать их в HTML, RTF, PS и другие форматы так же, как это делается с Руководством. Это заставляет вас перестраивать Руководство каждый раз, когда вы хотите видеть результат изменений только в одной главе.


Глава 7. Процесс построения документации

Главная цель этой главы заключается в четком описании того, как организован процесс построения документации, а также как внести изменения в этот процесс.

После чтения этой главы вы должны:


7.1. Набор инструментов для построения документации FreeBSD

Вот ваши инструменты. Используйте их любым доступным вам способом.

  • Основным инструментом построения, который вам понадобится, является make, и конкретно Berkeley Make.

  • Построение пакаджа выполняется утилитой FreeBSD pkg_create. Если вы не используете FreeBSD, вы либо обходитесь без пакаджей, либо компилируете исходные тексты самостоятельно.

  • gzip нужен для создания компрессированных версий документа. Компрессия bzip2 и архивы zip также поддерживаются. tar поддерживается, но он требуется при построении пакаджа.

  • install является методом, используемым по умолчанию для установки документации. Однако есть и альтернативы.

Замечание: Сомнительно, что вы не сможете найти последние утилиты, они отмечены для полноты.


7.2. Понимание make-файлов в дереве документации

В дереве Проекта Документирования FreeBSD имеется три основных типа файлов Makefile.


7.2.1. Make-файлы в подкаталоге

Эти Makefile обычно имеют такой вид:

SUBDIR =articles
SUBDIR+=books

COMPAT_SYMLINK = en

DOC_PREFIX?= ${.CURDIR}/..
.include "${DOC_PREFIX}/share/mk/doc.project.mk"

Обзорно, первые четыре непустые строчки задают make-переменные, SUBDIR, COMPAT_SYMLINK и DOC_PREFIX.

Первая декларация SUBDIR, как и COMPAT_SYMLINK, показывает, как присваивать значение переменной, переопределяя все ранее определенные значения.

Вторая инструкция SUBDIR показывает, как значение добавляется к текущему значению переменной. Значение переменной SUBDIR теперь соответствует articles books.

Присвоение DOC_PREFIX показывает, как значение присваивается переменной, но только если оно еще не определено. Это полезно, если DOC_PREFIX не соответствует тому, что полагает об этом Makefile - пользователь может переопределить это значение и дать правильное значение.

Так что все это значит? SUBDIR определяет, в какие вложенные подкаталоги должна быть передана работа по построению.

COMPAT_SYMLINK касается исключительно символических ссылок для достижения совместимости (достаточно удивительно) языков с их официальной кодировкой (doc/en должна указывать на en_US.ISO-8859-1).

DOC_PREFIX является маршрутом к корню дерева Проекта Документирования FreeBSD. Его не всегда легко найти и легко переопределить для достижения гибкости. .CURDIR является встроенной make-переменной, хранящей путь к текущему каталогу.

В последней строке включается системный make-файл doc.project.mk Проекта Документирования FreeBSD, доступный всем проектам, который является связующим звеном, преобразующим эти переменные во встроенные инструкции.


7.2.2. Make-файлы для документации

Эти make-файлы задают набор make-переменных, которые описывают, как построить документацию, расположенную в этом каталоге.

Вот пример:

MAINTAINER=nik@FreeBSD.org

DOC?= book

FORMATS?= html-split html

INSTALL_COMPRESSED?= gz
INSTALL_ONLY_COMPRESSED?=

# SGML content
SRCS=  book.sgml

DOC_PREFIX?= ${.CURDIR}/../../..

.include "$(DOC_PREFIX)/share/mk/docproj.docbook.mk"

Переменная MAINTAINER очень важна. Эта переменная дает возможность указать владельца документа в Проекте Документирования FreeBSD, когда вы становитесь ответственным за его поддержку.

DOC является именем (предполагается расширение .sgml) главного документа, создаваемого в этом каталоге. В SRCS перечисляются все отдельные файлы, которые составляют документ. Сюда также должны быть включены важные файлы, изменение которых должно приводить к перестроению.

FORMATS указывает используемые по умолчанию форматы, которые применяются при построении этого документа. INSTALL_COMPRESSED является списком методов компрессии, которые должны использоваться при построении документа. INSTALL_ONLY_COMPRESS, пустая по умолчанию, должна быть непустой, если требуется построить только скомпрессированные документы.

Замечание: Назначение опциональных переменных обсуждается в предыдущем разделе.

Переменная DOC_PREFIX у включающие директивы должны быть вам уже известны.


7.3. Включаемые make-файлы Проекта Документирования FreeBSD

Лучше всего это описывается при обсуждении кода. Вот системные включаемые файлы:

  • doc.project.mk является главным включаемым файлом проекта, который включает все остальные включаемые файлы, по мере необходимости.

  • doc.subdir.mk обрабатывает прохождение по дереву документов в процессе построения и установки.

  • doc.install.mk содержит переменные, которые отражаются на правах доступа и установке документов.

  • doc.docbook.mk включается, если значением переменной DOCFORMAT является docbook и установлена переменная DOC.


7.3.1. doc.project.mk

Рассмотрим пример:

DOCFORMAT?=    docbook
MAINTAINER?=    doc@FreeBSD.org

PREFIX?=    /usr/local
PRI_LANG?=  en_US.ISO8859-1

.if defined(DOC)
.if ${DOCFORMAT} == "docbook"
.include "doc.docbook.mk"
.endif
.endif

.include "doc.subdir.mk"
.include "doc.install.mk"

7.3.1.1. Переменные

Переменным DOCFORMAT и MAINTAINER заданы значения по умолчанию, если они не установлены в make-файле документа.

PREFIX является каталогом, под которым установлены инструменты для построения документации. При обычной установке портов и пакаджей это /usr/local.

PRI_LANG должна быть установлена в значение, соответствующее языку и кодировке, являющейся естественной для тех пользователей, кому предназначена документация. По умолчанию это US English.

Замечание: PRI_LANG не влияет на то, какие документы могут или будут строиться. Ее основное назначение - создание ссылок на часто упоминаемые документы в корне установки документации FreeBSD.


7.3.1.2. Условия

Строка .if defined(DOC) является примером make-условия, которое, как и в других программах, определяет дальнейшие действия, если какое-то условие выполняется или нет. defined является функцией, которая возвращает информацию о том, определена данная переменная или нет.

Затем .if ${DOCFORMAT} == "docbook" проверяет, является ли значением переменной DOCFORMAT "docbook", и в этом случае включается файл doc.docbook.mk.

Две строки .endif закрывают два вышестоящих условия, отмечая конец их действия.


7.3.2. doc.subdir.mk

Этот файл слишком долго описывать на примерах, вы сможете разобраться с ним сами на основе знаний, полученных из предыдущих глав и некоторой вспомогательной информации, дающейся здесь.


7.3.2.1. Переменные

  • SUBDIR представляет из себя список подкаталогов, которые должны быть охвачены процессом построения.

  • ROOT_SYMLINKS является именами каталогов, которые должны указывать на корень установки документа от их действительных положений, если текущий язык является основным (что задается переменной PRI_LANG).

  • COMPAT_SYMLINK описано в разделе о make-файле подкаталога.


7.3.2.2. Цели и макросы

Зависимости описываются парами target: dependency1 dependency2 ..., и когда вам нужно построить target, вам необходимо сначала построить список зависимостей.

После описательной пары могут следовать инструкции о том, как построить цель, если процесс преобразования цели к зависимостям ранее не был определен, или если это конкретное преобразование не совпадает с применяемым по умолчанию методом.

Особая зависимость .USE задает эквивалент макроса.

_SUBDIRUSE: .USE
.for entry in ${SUBDIR}
    @${ECHO} "===> ${DIRPRFX}${entry}"
    @(cd ${.CURDIR}/${entry} && \
    ${MAKE} ${.TARGET:S/realpackage/package/:S/realinstall/install/} DIRPRFX=${DIRPRFX}${entry}/ )
.endfor

В вышеприведенном фрагменте _SUBDIRUSE теперь является макросом, который будет выполнять заданные команды, если задан в списке зависимостей.

Что отличает этот макрос от других целей? В основном то, что он выполняется после инструкций, данных в процедуре построения, в качестве зависимости для которой он перечислен, и это не влияет на .TARGET, которая является переменной, содержащей название текущей выполняемой цели.

clean: _SUBDIRUSE
    rm -f ${CLEANFILES}

В вышеприведенном фрагменте clean будет использовать макрос _SUBDIRUSE после того, как выполнит инструкцию rm -f ${CLEANFILES}. В результате это приведет к тому, что clean будет углубляться по дереву каталогов, удаляя файлы после перехода ниже, а не на пути назад.


7.3.2.2.1. Предопределенные цели
  • Цели install и package обе переходят вниз по дереву каталогов, вызывая собственные выполняющие реальную работу версии в подкаталогах. (realinstall и realpackage соответственно)

  • clean удаляет файлы, созданные в процессе построения (и тоже переходит вниз по дереву каталогов). cleandir делает то же самое и также удаляет каталог, если он есть.


7.3.2.3. Подробности об условиях

  • exists является еще одной функцией условия, которая возвращает истину, если указанный файл существует.

  • empty возвращает истину, если данная переменная имеет пустое значение.

  • target возвращает истину, если указанная цель еще не существует.


7.3.2.4. Циклы в make (.for)

.for дает способ повторить набор инструкций для каждого элемента списка, заданного в переменной через пробел. Он делает это, присваивая переменной значение текущего элемента перебираемого списка.

_SUBDIRUSE: .USE
.for entry in ${SUBDIR}
    @${ECHO} "===> ${DIRPRFX}${entry}"
    @(cd ${.CURDIR}/${entry} && \
    ${MAKE} ${.TARGET:S/realpackage/package/:S/realinstall/install/} DIRPRFX=${DIRPRFX}${entry}/ )
.endfor

В примере выше если переменная SUBDIR пуста, то не предпринимается никаких действий; если она состоит из одного или более элементов, то инструкции между .for и .endfor будут повторены для каждого элемента, причем entry будет заменена значением текущего элемента.


Глава 8. Web-сервер

8.1. Подготовка

Найдите 200 Мбайт свободного дискового пространства. Вам потребуется место для инструментов SGML, части дерева CVS, временное пространство для построения и пространство для установки Web-страниц. Если у вас уже установлены инструменты SGML и дерево CVS, то вам нужно только около 100 Мбайт свободного дискового пространства.

Замечание: Удостоверьтесь, что ваши порты, относящиеся к документации, являются самыми последними. Если сомневаетесь, то удалите старые порты командой pkg_delete(1) перед тем, как устанавливать порт. К примеру, на данный момент мы завязаны на jade-1.2, а если у вас установлен пакет jade-1.1, то, пожалуйста, выполните

# pkg_delete jade-1.1

Настройте хранилище CVS. В дереве CVS вам нужны каталоги www, doc и ports (плюс, конечно же, CVSROOT). Пожалуйста, прочтите введение в CVSup по адресу Введение в CVSup о том, как получать зеркальную копию дерева CVS или его частей.

Достаточно иметь следующие наборы cvsup: www, doc-all, cvs-base и ports-base.

Эти наборы требуют около 105 Мбайт свободного дискового пространства.

Полное дерево CVS, включая src, doc, www и ports в настоящее время занимает около 940 Мбайт.


8.2. Построение Web-страниц с нуля

  1. Создайте каталог для построения с объёмом свободного пространства не менее 60 Мбайт и перейдите в него.

    # mkdir /var/tmp/webbuild
    # cd /var/tmp/webbuild
    
  2. Извлеките файлы SGML из дерева CVS.

    # cvs -R co www doc
    
  3. Перейдите в каталог www/en и запустите команду make(1) all для создания Web-страниц.

    # cd en
    # make all
    

8.3. Установка Web-страниц в ваш Web-сервер

  1. Если вы вышли из каталога en, то вернитесь в него.

    # cd path/www/en
    
  2. Запустите команду make(1) install, установив переменную DESTDIR в имя каталога, в который вы хотите установить файлы.

    # make DESTDIR=/usr/local/www install
    
  3. Если ранее вы устанавливали Web-страницы в тот же самый каталог, то в процессе установки не будут удалены ни одна из старых или устаревших страниц. К примеры, если вы перестраиваете и устанавливаете новую копию сайта каждый день, то эта команда найдет и удалит все файлы, которые не были обновлены в течение трех дней.

    # find /usr/local/www -ctime 3 -print0 | xargs -0 rm
    

8.4. Переменные окружения

CVSROOT

Расположение дерева CVS. Нужна.

# CVSROOT=/home/ncvs; export CVSROOT
ENGLISH_ONLY

Если она установлена и не пуста, то при выполнении make-файлов будут строиться и устанавливаться документы только на английском языке. Все переводы будут проигнорированы. Например:

# make ENGLISH_ONLY=YES all install

Если вы хотите снять установку значений переменной ENGLISH_ONLY и построить все страницы, включая переводы, то задайте переменной ENGLISH_ONLY пустое значение

# make ENGLISH_ONLY="" all install clean
WEB_ONLY

Если задана и не пуста, то при выполнении make-файлов будут построены и установлены страницы HTML только из каталога www. Все документы из каталога doc (Руководство, FAQ, Учебники) будут проигнорированы. К примеру:

# make WEB_ONLY=YES all install
NOPORTSCVS

Если задана, то при выполнении make-файлов файлы портов из хранилища cvs извлекаться не будут. Вместо этого будут скопированы файлы из /usr/ports (или из каталога, на который указывает переменная PORTSBASE).

CVSROOT является переменной окружения. Вы должны задать её в командной строке или в ваших настроечных файлах (например, ~/.profile).

WEB_ONLY, ENGLISH_ONLY и NOPORTSCVS являются переменными make-файлов. Вы можете задать их в файлах /etc/make.conf и Makefile.inc, работать с ними как с переменными окружения в командной строке или файлах командного процессора.


Глава 9. Переводы

Это FAQ для тех, кто переводит документацию FreeBSD (FAQ, Руководство, учебники, справочную систему и прочее) на различные языки.

Он в очень большой степени основан на FAQ о переводе из Немецкого Проекта Документирования FreeBSD, первоначально написанного Франком Грюндером (Frank Gründer) и переведенного обратно на английский язык Берндом Варкеном (Bernd Warken) .

FAQ поддерживает Группа Менеджеров Дерева Документации FreeBSD .

9.1. Зачем нужен FAQ?
9.2. Что означают сокращения i18n и l10n?
9.3. Есть ли список рассылки для переводчиков?
9.4. Нужны ли дополнительные переводчики?
9.5. Какие языки я должен знать?
9.6. Какое программное обеспечение я должен знать?
9.7. Как найти того, кто может переводить на тот же самый язык?
9.8. Никто не занимается переводом на мой язык. Что мне делать?
9.9. Я перевел некоторую документацию, куда ее переслать?
9.10. Я единственный, кто работает над переводом на этот язык, как мне прислать мой перевод?
9.11. Могу ли я включить в мой перевод текст, специфичный для языка или страны?
9.12. Как должны включаться символы, специфичные для языка?
9.13. Обращение к читателю
9.14. Нужно ли включать какую-либо дополнительную информацию в мои переводы?

9.1. Зачем нужен FAQ?

Все больше людей участвуют в списке рассылки freebsd-doc и выступают добровольцами для перевода документации FreeBSD на другие языки. Этот FAQ предназначен для ответа на их вопросы, чтобы они могли начать переводить документацию как можно быстрее.

9.2. Что означают сокращения i18n и l10n?

i18n означает internationalisation (интернационализация), а l10n означает localisation (локализация). Это просто общепринятые сокращения.

i18n можно прочитать как ''i'', за которой следует 18 символов, за которыми следует буква ''n''. Подобным же образом l10n это ''l'', за которым следуют 10 символов, за которыми идет буква ''n''.

9.3. Есть ли список рассылки для переводчиков?

Да. У различных групп перевода есть собственные списки рассылки. В списке проектов перевода находится более подробная информация о списках рассылки и веб сайтах каждого проекта перевода.

9.4. Нужны ли дополнительные переводчики?

Да. Чем больше людей работает над переводом, тем быстрее он выполняется, и тем быстрее изменения в документации на английском языке отражаются в переводимых документах.

Чтобы помогать нам, вам вовсе не нужно быть профессиональным переводчиком.

9.5. Какие языки я должен знать?

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

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

9.6. Какое программное обеспечение я должен знать?

Настоятельно рекомендуется поддерживать локальную копию хранилища CVS FreeBSD (по крайней мере части, относящейся к документации) при помощи CTM или CVSup. Глава Руководства "Отслеживание current во FreeBSD" описывает, как использовать эти приложения.

Вы должны уверенно владеть CVS. Эта программа позволит вам увидеть изменения между различными версиями файлов, которые составляют документацию.

[XXX что сделать -- написать учебник, показывающий использование CVSup для получения только документации, ее извлечения из хранилища и просмотра изменений между некоторыми двумя версиями]

9.7. Как найти того, кто может переводить на тот же самый язык?

На странице переводов Проекта Документирования перечислены рабочие группы, занимающиеся переводом, о которых известно на данный момент. Если кто-о уже занимается переводом документации на ваш язык, пожалуйста, не дублируйте их работу. Вместо этого обратитесь к ним с предложением помощи.

Если на этой странице нет никого, кто бы переводил на ваш язык, то пошлите сообщение в Список рассылки Проекта Документации FreeBSD на тот случай, если кто-то еще раздумывает над переводом, но еще не объявил об этом.

9.8. Никто не занимается переводом на мой язык. Что мне делать?

Поздравляем, вы только что начали ''FreeBSD ваш язык Documentation Translation Project''. Добро пожаловать в команду.

Первым делом определитесь, есть ли у вас свободное время. Так как пока вы единственный человек, работающий на вашем языке, то вы будете отвечать за публикацию вашей работы и координирование всех добровольцев, которые могут захотеть помочь вам.

Напишите письмо по электронной почте в адрес списка рассылки Проекта Документирования с анонсом того, что вы переводите документацию, чтобы страница переводов Проекта Документирования могла быть обновлена.

Если в вашей стране кто-то уже поддерживает зеркало FreeBSD, вы должны связаться с ним и попросить о предоставлении веб-пространства для вашего проекта, и, может быть, адреса электронной почты или создания списка рассылки.

Затем выберите документ и начните перевод. Лучше всего начать с чего-то сравнительно небольшого--FAQ или одного из учебников.

9.9. Я перевел некоторую документацию, куда ее переслать?

По обстоятельствам. Если вы уже работаете с группой по переводу (такой, как японской или немецкой), то у них есть собственные процедуры по обработке посылаемой им документации, и это описано на страницах их веб-серверов.

Если вы являетесь единственным человеком, работающим на некотором языке (или вы отвечаете за проект перевода и хотите отослать ваши изменения обратно в проект FreeBSD), то вы должны послать ваш перевод в проект FreeBSD (посмотрите следующий вопрос).

9.10. Я единственный, кто работает над переводом на этот язык, как мне прислать мой перевод?

или

Мы группа, занимающаяся переводом, и хотим переслать документацию, которую участники нашей группы перевели?

Сначала убедитесь, что ваш перевод правильно организован. Это значит, что он должен соответствовать существующему дереву документации и строиться без проблем.

На данный момент документация FreeBSD хранится в каталоге верхнего уровня с именем doc/. Каталоги ниже него именуются в соответствии с кодом языка, на котором написана документация, как это определено в ISO639 (/usr/share/misc/iso639 для версий FreeBSD новее, чем 20 января 1999).

Если ваш язык может кодироваться различными способами (к примеру, китайский), то здесь должны быть каталоги по одному для каждого формата кодирования, который вы предоставляете.

Наконец, для каждого документа должны иметься каталоги.

Например, гипотетический перевод на шведский может выглядеть примерно как

doc/
    sv_SE.ISO8859-1/
                 Makefile
                 books/
                       faq/
                           Makefile
                           book.sgml

sv_SE.ISO8859-1 является названием перевода, в форме язык.кодировка. Отметьте наличие двух make-файлов, которые будут использоваться для построения документации.

Воспользуйтесь утилитами tar(1) и gzip(1) для упаковки вашей документации, и пошлите ее в проект.

% cd doc
% tar cf swedish-docs.tar sv
% gzip -9 swedish-docs.tar

Поместите куда-нибудь swedish-docs.tar.gz. Если у вас нет собственного веб-пространства (возможно, ваш ISP не позволяет вам это делать), то вы можете написать по электронной почте Группа Менеджеров Дерева Документации FreeBSD и, если это возможно, договориться.

В любом случае вы должны использовать send-pr(1) для посылки сообщения, говорящего о том, что вы послали документацию. Будет весьма полезно, если вы сможете попросить других людей взглянуть на ваш перевод и сначала дважды его проверить, потому что вряд ли тот, кто будет помещать перевод в дерево проекта, свободно владеет языком.

Кто-то (скорее всего, Менеджер Проекта Документирования, в настоящее время это Группа Менеджеров Дерева Документации FreeBSD ) рассмотрит ваш перевод и удостоверится, что он собирается. В частности, будет проверяться следующее:

  1. Все ли ваши файлы используют строки RCS (такие, как "ID")?

  2. Срабатывает ли корректно команда make all в каталоге sv_SE.ISO8859-1?

  3. Правильно ли работает команда make install?

Если имеются какие-то проблемы, то тот, кто рассматривал вашу работу, возвратите ее вам для дальнейшей работы.

Если с вашим переводом проблем не возникло, то он будет помещен в дерево как можно скорее.

9.11. Могу ли я включить в мой перевод текст, специфичный для языка или страны?

Мы предпочитаем, чтобы вы этого не делали.

Например, положим, что вы переводите Руководство на корейский язык, и хотите включить раздел о корейских распространителях в ваше Руководство.

Нет причин, по которым эта информация не должна появиться также в версиях на английском (или немецком, испанском или японском, или ...) языке. Вероятно, что англоговорящий человек в Корее может попытаться найти копию FreeBSD при помощи этой информации. Это также помогает увеличить представительство FreeBSD во всем мире, что неплохо.

Если у вас имеется информация, специфичная для страны, то, пожалуйста, пришлите ее нам в виде изменений к Руководству на английском языке (при помощи send-pr(1)), а затем переведите изменение обратно на ваш язык в переводимом Руководстве.

Спасибо.

9.12. Как должны включаться символы, специфичные для языка?

Символы не из кодовой таблицы ASCII должны включаться в документацию при помощи сущностей SGML.

Если описывать кратко, то они выглядят как знак амперсанда (&), за которым следует имя сущности и точка с запятой (;).

Имена сущностей определены в ISO8879, который находится в дереве портов как textproc/iso8879.

Несколько примеров включения

Сущность: &eacute;

Отображение: é

Описание: Маленькое ''e'' с сильным ударением

Сущность: &Eacute;

Отображение: É

Описание: Большое ''E'' с сильным ударением

Сущность: &uuml;

Отображение: ü

Описание: Маленькое ''u'' с умляутом

После установки вами порта iso8879 в файлах из каталога /usr/local/share/sgml/iso8879 содержится полный список.

9.13. Обращение к читателю

В документах на английском языке к читателю обращаются на ''ты/вы'' (you), и здесь нет формального либо неформального разделения, каковое есть в некоторых языках.

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

9.14. Нужно ли включать какую-либо дополнительную информацию в мои переводы?

Да.

Заголовок английской версии любого документа выглядит примерно так;

<!--
     The FreeBSD Documentation Project

     $FreeBSD: doc/en_US.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.5 2000/07/07 18:38:38 dannyboy Exp $
-->

Точное написание может меняться, но здесь всегда будет присутствовать строка $FreeBSD$ и фраза The FreeBSD Documentation Project. Заметьте, что часть $FreeBSD автоматически расширяется в CVS, так что для новых файлов она должна быть пустой (просто $FreeBSD$).

Переведенные вами документы должны включать собственную строку $FreeBSD$ и изменять строку FreeBSD Documentation Project на The FreeBSD язык Documentation Project.

Кроме того, вы должны добавить третью строку, которая указывает, на основе какой версии английского текста сделан документ.

Так, испанская версия этого файла может начинаться с

<!--
     The FreeBSD Spanish Documentation Project

     $FreeBSD: doc/es_ES.ISO8859-1/books/fdp-primer/translations/chapter.sgml,v 1.3 1999/06/24 19:12:32 jesusr Exp $
     Original revision: 1.11
-->

Глава 10. Стиль написания

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

Используйте Американский вариант английского языка

Существует несколько вариантов английского языка, с отличающимися вариантами записи одинаковых слов. В случае, если написания отличаются - используйте американский вариант. ''color'', а не ''colour'', ''rationalize'', а не ''rationalise'', и так далее.

Замечание: Использование британского английского может быть принято при предоставлении статей, но написание должно быть одинаковым во всём документе. Другие документы, такие как книги, страницы Web-сайта, справочные страницы и так далее, должны использовать американский английский.

Не используйте сокращений

Не используйте кратких форм в английском тексте. Всегда пишите фразу полностью. Будет неправильно написать ''Don't use contractions''.

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

Используйте несколько запятых

В списке объектов внутри параграфа отделяйте каждый пункт от другого при помощи запятых. В английском тексте отделяйте последний пункт от других при помощи запятой и слова ''and''.

К примеру, рассмотрим следующее:

This is a list of one, two and three items.

Это список из трех объектов ''one'', ''two'' и ''three'', или список из двух пунктов ''one'' и ''two and three''?

Лучше быть точным и включить запятую:

This is a list of one, two, and three items.

Избегайте лишних фраз

Попытайтесь не использовать ненужных фраз. В частности, ''the command'', ''the file'' и ''man command'', наверное, излишни.

Эти два примера показывают это для команд. Второй вариант предпочтителен.

Use the command cvsup to update your sources

Use cvsup to update your sources

Эти два примера показывают это для имен файлов. Предпочтителен второй вариант.

... in the filename /etc/rc.local...

... in /etc/rc.local...

Эти два примера показывают это для ссылок на справочную систему. Предпочтителен второй вариант (второй вариант использует <citerefentry>).

See man csh for more information.

See csh(1)

Два пробела в конце предложений

Всегда используйте два пробела в конце предложений, так как это усиливает читабельность, и облегчает использование таких инструментов, как Emacs.

Хотя могут быть возражения, что заглавная буква, которая следует за точкой, обозначает новое предложение, это не тот случай, особенно при использовании имен. ''Jordan K. Hubbard'' является хорошим примером; в этом имени есть заглавная H, которая следует за точкой и пробелом, но это не новое предложение.

Более подробную информацию о стиле написания можно найти в работе Уильяма Странка Elements of Style.


10.1. Руководство по стилю

Для того, чтобы исходный текст Руководства был выполнен в одном стиле, когда много разных людей его редактируют, пожалуйста, следуйте следующим соглашениям о стиле.


10.1.1. Регистр букв

Метки вводятся в нижнем регистре, <para>, а не <PARA>.

Текст, который появится в контексте SGML, обычно пишется в верхнем регистре, <!ENTITY...> и <!DOCTYPE...>, но не <!entity...> и <!doctype...>.


10.1.2. Акронимы

Акронимы обычно должны расшифровываться при первом появлении в книге, например: "Network Time Protocol (NTP)." После определения акронима, обычно используется только он, (а не термин целиком, если только в данном случае использование полного термина не предпочтительнее). Обычно акронимы определяются только один раз во всей книге. Но если желаете, вы можете определять их в каждой главе.

Первые три раза акроним должен помещаться внутри тегов <acronym>, с атрибутом role, где определен полный термин. Это позволяет создавать ссылку на глоссарий, и выводить полное описание при наведении на термин курсора мыши.


10.1.3. Отступы

Каждый файл начинается с отступа в колонке 0, независимо от отступа файла, который может включать этот файл.

Открывающие метки увеличивают отступ на 2 пробела. Закрывающие метки в свою очередь уменьшают отступ на 2 пробела. Заменяйте начальные пробелы символами табуляции, насколько это возможно. Не используйте пробелы перед символами табуляции, и не добавляйте дополнительных пробелов в конце строки. Содержимое элементов должно иметь отступ в два пробела, если содержимое превышает по размеру одну строку.

Например, исходный код этого раздела выглядит примерно так:

+--- This is column 0
V
<chapter>
  <title>...</title>

  <sect1>
    <title>...</title>

    <sect2>
      <title>Отступы</title>

      <para>Каждый файл начинается с отступа в колонке 0,
    <emphasis>независимо</emphasis> от отступа файла, который может
    включать этот файл.</para>

      <para>Каждая открывающая метка увеличивает отступ на 2 пробела, а каждая
    закрывающая метка уменьшает его на 2 пробела.  Заменяйте начальные
    пробелы символами табуляции, насколько это возможно.  Не используйте
    пробелы перед символами табуляции, и не добавляйте дополнительных
    пробелов в конце строки.  Содержимое элементов должно иметь отступ в
    два пробела, если содержимое превышает по размеру одну строку.</para>

      ...   
    </sect2>
  </sect1>
</chapter>

Если для редактирования файлов вы используете Emacs или XEmacs, то должен быть автоматически загружен sgml-mode, а локальные переменные Emacs в конце каждого файла должны заставить включить эти стили.

Пользователи Vim могут использовать следующие команды для конфигурации:

augroup sgmledit
  autocmd FileType sgml set formatoptions=cq2l " Special formatting options
  autocmd FileType sgml set textwidth=70       " Wrap lines at 70 columns
  autocmd FileType sgml set shiftwidth=2       " Automatically indent
  autocmd FileType sgml set softtabstop=2      " Tab key indents 2 spaces
  autocmd FileType sgml set tabstop=8          " Replace 8 spaces with a tab
  autocmd FileType sgml set autoindent         " Automatic indentation
augroup END



10.1.4. Стиль меток

10.1.4.1. Отделение меток

Метки, которые находятся на том же уровне, что и предыдущая метка, должны отделяться пустой строкой, а те, что не находятся на той же самой позиции, что и предыдущая метка, не должны:

<article>
  <articleinfo>
    <title>NIS</title>

    <pubdate>Октябрь 1999</pubdate>

    <abstract>
      <para>...
    ...
    ...</para>
    </abstract>
  </articleinfo>

  <sect1>
    <title>...</title>

    <para>...</para>
  </sect1>

  <sect1>
    <title>...</title>

    <para>...</para>
  </sect1>
</article>

10.1.4.2. Отделение меток

Такие метки, как <itemizedlist>, которые всегда будут иметь метки внутри них, и на самом деле сами в себе текстовых данных не содержат, всегда располагаются на одном уровне.

Таким меткам, как <para> и <term>, не нужны другие метки для обычных символьных данных, а их содержимое начинается сразу же после метки, на той же самой строке.

То же самое относится к закрытию этих двух типов меток.

Это приводит к очевидной проблеме при смешивании этих меток.

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

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


10.1.5. Изменения, затрагивающие только количество пробелов

При коммите изменений не вносите изменения в содержимое одновременно с изменениями в форматировании.

Это нужно, потому что команды, которые переводят Руководство на другие языки, могут быстро увидеть, как изменилось содержимое с вашим коммитом без раздумий над тем, изменилась ли строка из-за содержания или из-за другого расположения пробелов.

К примеру, если вы добавили два предложения в абзац, и при этом длины строк в абзаце теперь превысила 80 символов, сначала выполните коммит ваших изменений с длинными строками. Затем измените перенос строк и закоммитьте второе изменение. В сообщении, описывающем коммит по второму изменению, обязательно укажите, что это несущественное изменение, и что команды переводчиков могут его игнорировать.


10.1.6. Непрерываемые пробелы

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

Data capacity ranges from 40 MB to 15GB.  Hardware compression ...

Общая сущность &nbsp; запрещает перенос строки между частями относящимися друг к другу. Используйте прерываемые пробелы в подобных случаях:

  • между цифрами и величинами:

    57600&nbsp;bps
    
  • между названием программы и номером версии:

    FreeBSD&nbsp;4.7
    
  • между многословными названиями (используйте осторожно, когда применяете это правило к фразам содержащим 3-4 и более слов. Например: ''The FreeBSD Brazilian Portuguese Documentation Project''):

    Sun&nbsp;Microsystems
    

10.2. Словарь

Далее следует краткий список слов, написание которых дано в виде, который должен использоваться в Проекте Документирования FreeBSD. Если в этом списке нет слова, которое вы ищете, то обратитесь к словарю O'Reilly.

  • 2.2.X

  • 4.X-STABLE

  • CD-ROM

  • DoS (Denial of Service)

  • Ports Collection

  • IPsec

  • Internet

  • MHz

  • Soft Updates

  • Unix

  • disk label

  • email

  • file system

  • manual page

  • mail server

  • name server

  • web server


Глава 11. Использование Emacs в режиме sgml-mode

Последние версии Emacs или Xemacs (которые доступны из коллекции портов) содержат очень полезный пакет под названием PSGML. Автоматически вызываемый при загрузке файла с расширением .sgml или при наборе команды M-x sgml-mode, он является основным режимом для работы с файлами SGML, элементами и атрибутами.

Понимание некоторых команд, которые доступны в этом режиме, может значительно облегчить работу с документами SGML, такими, как Руководство.

C-c C-e

Вызывает sgml-insert-element. Вам будет задан вопрос об имени элемента для вставки в текущую позицию. Вы можете использовать клавишу TAB для дополнения имени элемента. Элементы, использование которых запрещено в текущей позиции, будут недоступны.

Будут вставлены начало и конец метки элемента. Если элемент содержит другие, обязательные элементы, то они тоже будут вставлены.

C-c =

Вызывает sgml-change-element-name. Поместите указатель внутри элемента и вызовите эту команду. Вам будет задан вопрос о новом имени элемента. Как начальная, так и конечная метки текущего элемента будут изменены на новые.

C-c C-r

Вызывает sgml-tag-region. Выделите некоторый текст (переместитесь на начало текста, нажмите C-пробел, перейдите в конец текста, нажмите C-пробел), и вызовите эту команду. Вам будет задан вопрос об используемом элементе. Этот элемент затем будет вставлен непосредственно перед и после отмеченной вами области.

C-c -

Вызывает sgml-untag-element. Поместите указатель между начальной и конечной меткой элемента, который вы хотите удалить, и запустите эту команду. Начальная и конечная метки элемента будут удалены.

C-c C-q

Вызывает sgml-fill-element. Рекурсивно заполняет (то есть переформатирует) содержимое, начиная от текущего элемента. Заполнение будет затрагивать содержимое, для которого важны пробелы, такое, как внутри элементов <programlisting>, так что запускайте эту команду с осторожностью.

C-c C-a

Вызывает sgml-edit-attributes. Открывает второй буфер, содержащий список всех атрибутов для ближайшего закрывающего элемента и их текущие значения. Используйте TAB для перемещения между атрибутами, C-k для удаления существующего значения и замены его новым, C-c для закрытия этого буфера и возврата к основному документу.

C-c C-v

Вызывает sgml-validate. Выдает запрос на подтверждение сохранения текущего документа (если это нужно), а затем запускает проверку SGML. Выдача проверяющего процесса передается в новый буфер, и вы затем можете переходить от одной проблемной точки к другой, исправляя при этом ошибки разметки.

Несомненно, что в этом режиме имеются и другие полезные функции, но здесь отмечены те, что я использую чаще всего.

Вы также можете использовать следующие значения в .emacs для настройки правильных значений пропусков, выравнивания и ширины строки для работы над Проектом Документации.

    (setq sgml-mode-hook
      '(lambda ()
     (setq fill-column 70
           indent-tabs-mode nil
           next-line-add-newlines nil
           standard-indent 2)
     (auto-fill-mode t)))
 

Глава 12. Дополнительные источники информации

Этот документ определенно касается не всех аспектов SGML, перечисленных DTD и Проекта Документирования FreeBSD. Более полную информацию по этим вопросам можно найти на следующих веб-сайтах.


12.2. SGML


12.4. DocBook


Приложение A. Примеры

В этом приложении находятся примеры файлов SGML и команд, которые вы можете использовать для преобразования их от одного формата к другому. Если вы успешно установили инструменты Проекта Документирования, то вы должны суметь непосредственно использовать эти примеры.

Эти примеры не исчерпывающи--в них содержатся не все элементы, которые вам могут понадобиться, в частности, те, что понадобятся в первую очередь. Примеры разметки DocBook вы можете найти в исходных текстах SGML для этого и других документов, которые находятся в наборе CVSup doc, или в сети с начальной страницей http://www.FreeBSD.org/cgi/cvsweb.cgi/doc/.

Во избежание путаницы в этих примерах используется стандартный DocBook 4.1 DTD, а не расширение FreeBSD. В них также используются стандартные таблицы стилей, которые распространяет Норм Уолш (Norm Walsh), а не те, что содержат дополнительные настройки, относящиеся к Проекту Документирования FreeBSD. Это делает их более полезными в качестве общих примеров для DocBook.


A.1. DocBook <book>

Пример A-1. DocBook <book>

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.1//EN">

<book>
  <bookinfo>
    <title>Пример книги</title>

    <author>
      <firstname>Ваше имя</firstname>
      <surname>Ваша фамилия</surname>
      <affiliation>
    <address><email>foo@example.com</email></address>
      </affiliation>
    </author>

    <copyright>
      <year>2000</year>
      <holder>Строка об авторских правах</holder>
    </copyright>

    <abstract>
      <para>Если в вашей книге есть краткое содержание, то оно должно быть
    здесь.</para>
    </abstract>
  </bookinfo>

  <preface>
    <title>Предисловие</title>

    <para>В вашей книге может быть предисловие, и в этом случае оно должно быть
      размещено здесь.</para>
  </preface>

  <chapter>
    <title>Моя первая глава</title>

    <para>Это первая глава моей книги.</para>

    <sect1>
      <title>Мой первый раздел</title>

      <para>Это первый раздел моей книги.</para>
    </sect1>
  </chapter>
</book>

A.2. DocBook <article>

Пример A-2. DocBook <article>

<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN">

<article>
  <articleinfo>
    <title>Пример статьи</title>

    <author>
      <firstname>Ваше имя</firstname>
      <surname>Ваша фамилия</surname>
      <affiliation>
    <address><email>foo@example.com</email></address>
      </affiliation>
    </author>

    <copyright>
      <year>2000</year>
      <holder>Здесь строка об авторских правах</holder>
    </copyright>

    <abstract>
      <para>Если в вашей статье есть краткое содержание, то оно должно быть
    здесь.</para>
    </abstract>
  </articleinfo>

  <sect1>
    <title>Мой первый раздел</title>

    <para>Это первый раздел моей статьи.</para>

    <sect2>
      <title>Мой первый подраздел</title>

      <para>Это первый подраздел моей статьи.</para>
    </sect2>
  </sect1>
</article>

A.3. Получение форматированного вывода

В этом разделе предполагается, что вы установили программное обеспечение, перечисленное в порту textproc/docproj вручную либо при помощи порта. Далее предполагается, что ваше программное обеспечение установлено в каталогах под /usr/local/, а каталог с установленными выполнимыми файлами есть в переменной PATH. Настройте маршруты поиска по необходимости в соответствии с вашей системой.


A.3.1. Использование Jade

Пример A-3. Преобразование DocBook в HTML (один большой файл)

% jade -V nochunks \  (1)
    -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ (2)
    -c /usr/local/share/sgml/docbook/catalog \
    -c /usr/local/share/sgml/jade/catalog \
    -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \(3)
    -t sgml (4) file.sgml > file.html (5)
(1)
Задает параметр nochunks таблицам стилей, перенаправляя весь вывод в STDOUT (при помощи таблиц стилей от Норма Уолша).
(2)
Задает каталоги, которые будет обрабатывать Jade. Требуются три каталога. Первый является каталогом, содержащим информацию о таблицах стилей DSSSL. Второй содержит информацию о DocBook DTD. Третий содержит данные, специфичные для Jade.
(3)
Задает полный маршрут к таблице стилей DSSSL, которую будет использовать Jade при обработке документа.
(4)
Указывает Jade на выполнение преобразования от одного DTD к другому. В этом случае входная информация будет преобразована из DocBook DTD в HTML DTD.
(5)
Задает файл, который должна обработать система Jade, и перенаправить вывод в указанный файл .html.

Пример A-4. Преобразование DocBook в HTML (несколько маленьких файлов)

% jade \
    -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ (1)
    -c /usr/local/share/sgml/docbook/catalog \
    -c /usr/local/share/sgml/jade/catalog \
    -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl \(2)
    -t sgml (3) file.sgml (4)
(1)
Задает каталоги, которые нужно обработать Jade. Требуются три каталога. Первый является каталогом, в котором находится информация о таблицах стилей DSSSL. Второй содержит информацию о DocBook DTD. Третий содержит информацию, специфичную для Jade.
(2)
Задает полный путь к таблице стилей DSSSL, которую Jade будет использовать при обработке документа.
(3)
Указывает Jade на выполнение преобразования от одного DTD к другому. В этом случае входная информация будет преобразована из DocBook DTD в HTML DTD.
(4)
Задает файл, который должен обработать Jade. Таблицы стилей определяют, как будут именоваться отдельные файлы HTML, и имя ''корневого'' файла, то есть того, в котором находится начало документа.

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

Пример A-5. Преобразование DocBook в Postscript

Исходный файл SGML должен быть преобразован в файл TeX.

% jade -Vtex-backend \ (1)
    -c /usr/local/share/sgml/docbook/dsssl/modular/catalog \ (2)
    -c /usr/local/share/sgml/docbook/catalog \
    -c /usr/local/share/sgml/jade/catalog \
    -d /usr/local/share/sgml/docbook/dsssl/modular/print/docbook.dsl \(3)
    -t tex (4) file.sgml
(1)
Настройка таблиц стилей на использование различных опций, специфичных для создания выходной информации для TeX.
(2)
Задает каталоги, которые нужно обработать Jade. Требуются три каталога. Первый является каталогом, в котором находится информация о таблицах стилей DSSSL. Второй содержит информацию о DocBook DTD. Третий содержит информацию, специфичную для Jade.
(3)
Задает полный путь к таблице стилей DSSSL, которую Jade будет использовать при обработке документа.
(4)
Указывает Jade на преобразование выходной информации в формат TeX.

Сгенерированный файл .tex теперь должен быть пропущен через tex, с указанием пакета макросов &jadetex.

% tex "&jadetex" file.tex

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

Не беспокойтесь, если при этом вы увидите предупреждающие сообщения, такие, как LaTeX Warning: Reference `136' on page 5 undefined on input line 728..

При втором запуске документ повторно обрабатывается, но при этом некоторая часть информации уже известна (такая, как длина страницы документа). Это позволяет зафиксировать индексные записи и другие перекрестные ссылки.

При третьем проходе выполняются необходимые оставшиеся исправления.

На этом этапе выходной информацией будет file.dvi.

Наконец, запуск dvips преобразует файл .dvi в Postscript.

% dvips -o file.ps file.dvi

Пример A-6. Преобразование DocBook в PDF

Первая часть этого процесса идентична той, что выполняется при преобразовании DocBook в Postscript, используется та же самая команда jade (Прим. A-5).

Когда будет сгенерирован файл .tex, вы запускаете pdfTeX. Однако при этом нужно использовать пакет макросов &pdfjadetex.

% pdftex "&pdfjadetex" file.tex

И снова выполняйте эту команду три раза.

При этом будет получен файл file.pdf, который больше обрабатывать не нужно.

Примечания

[1]

P - Параметризированные сущности используют символ P - процента.

[2]

Это позор. Представьте все проблемы и хэки (такие, как Server Side Includes), которых можно было бы избежать, если бы это было сделано.

[3]

Краткая история находится по адресу http://www.oasis-open.org/committees/docbook/intro.shtml.

[4]

В DocBook есть и другие типы элементов списка, но пока мы их не рассматриваем.


Этот, и другие документы, могут быть скачаны с ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

По вопросам, связанным с FreeBSD, прочитайте документацию прежде чем писать в <questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите <doc@FreeBSD.org>.
По вопросам, связанным с русским переводом документации, пишите в рассылку <frdp@FreeBSD.org.ua>.
Информация по подписке на эту рассылку находится на сайте проекта перевода.