Учебник по Проекту Документирования 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