Comments 55
Тот же XML можно писать в формате xml.tree, а потом конвертировать в собственно xml. Например:
? xml
version \1.0
encoding \UTF-8
book
@ xml:id \simple_book
@ xmlns \http://docbook.org/ns/docbook
@ version \5.0
title \Very simple book
chapter
@ xml:id \chapter_1
title \Chapter 1
para \Hello world!
para
\I hope that your day is proceeding
emphasis \splendidly
\!
chapter
@ xml:id \chapter_2
title \Chapter 2
para \Hello again, world!<?xml version="1.0" encoding="UTF-8"?>
<book xml:id="simple_book" xmlns="http://docbook.org/ns/docbook" version="5.0">
<title>Very simple book</title>
<chapter xml:id="chapter_1">
<title>Chapter 1</title>
<para>Hello world!</para>
<para>I hope that your day is proceeding <emphasis>splendidly</emphasis>!</para>
</chapter>
<chapter xml:id="chapter_2">
<title>Chapter 2</title>
<para>Hello again, world!</para>
</chapter>
</book>
В чём-то — да, а в чём-то просто вымораживает:
We address the initial-value problem
!bt
\begin{align}
u'(t) &= -au(t), \quad t \in (0,T], label{ode}\\
u(0) &= I, label{initial:value}
\end{align}
!etИли таблички аски-разметкой — это такой ад их редактировать и вручную выравнивать.
С таблицами вообще всё печально — не очень понятно какой синтаксис наилучший.
Я когда пилил свой маркдаун-подобный синтаксис делал так:
--
|
| *Колонка 1*
| *Колонка 2*
| *Колонка 3*
--
| *Строка 1*
| Значение 1х1
| Значение 1х2
| Значение 1х3
--
| *Строка 2*
| Значение 2х1
| Значение 2х2
| Значение 2х3Когда колонок не слишком много — вполне норм. Когда много — лучше что-нибудь типа такого:
--
| name
| field1 : *Колонка 1*
| field2 : *Колонка 2*
| field3 : *Колонка 3*
| field4 : *Колонка 4*
| field5 : *Колонка 5*
| field6 : *Колонка 6*
--
| name : *Строка 1*
| field1 : Значение 1х1
| field2 : Значение 1х2
| field3 : Значение 1х3
| field4 : Значение 1х4
| field5 : Значение 1х5
| field6 : Значение 1х6
--
| name : *Строка 2*
| field1 : Значение 2х1
| field2 : Значение 2х2
| field3 : Значение 2х3
| field4 : Значение 2х4
| field5 : Значение 2х5
| field6 : Значение 2х6Возможность такая должна быть, в принципе такой синтаксис этого не запрещает.
| |*Колонка 1*|*Колонка 2*|*Колонка 3*
|----------|:-|--|-:
|*Строка 1*|Значение 1х1|Значение 1х2|Значение 1х3
|*Строка 2*|Значение 2х1|Значение 2х2|Значение 2х3| |*Колонка 1*|*Колонка 2*|*Колонка 3*
|----------|:-|--|-:
|*Строка 1*|Значение 1|Значение 2|Значение в ячейке по координатам 1х3|Ещё одно значение 4|И опять 25
|*Строка 2*|Значение в ячейке по координатам 2x1|2|3|4|Значение 5Попробуйте не запутаться.
И что с того?
Во-вторых, да, считать в уме это дурная работа (хотя уметь нужно) т.к. компьютер делает это сильно эффективнее, надо мозги загружать тем, что компьютер не умеет делать.
Нормальный такой теховский код. Всяко проще, чем ноты с листа читать, например. :)
Плюс ещё бывают несколько разных указателей в конце, для которых нужен xindy, а как должны быть представлены указатели в электронной книге формата epub или mobi, я пока для себя не уяснил.
Но точно мне говорили что fb2 шустрее работает, товарищ просил сделать именно его т.к. остальное у него тормозило на телефоне.
Да, но проблема в том, что epub и fb2, как мне кажется, гораздо беднее чем pdf, и скажем, формулы им надо передавать рисунками, скорее всего.
Позвольте добавить свои пять копеек: в свое время я также долго перебирал, пробовал и использовал разные форматы, включая все вышеупомянутые. Для начала хотел бы напомнить про современный HTML — он имеет всю нужную семантику, например теги <section> и <article>. Явное преимущество — не нужно никаких дополнительных компиляций, простое обновление страницы достаточно. Из недостатков, конечно, отсутствие расширяемости и макроподстановок. Лично для меня главный недостаток — нельзя вставлять код с подсветкой синтаксиса (конечно, можно прикрутить highlight.js, но тогда уже можно забыть про конвертацию в PDF).
На данный момент я остановился на Scalateχ. Это весьма специфическое решение, но для моих нужд вполне подходит:
- используются HTML-теги, не нужно изучать новый язык разметки;
- полное расширение функциональности, например, вместо того, чтобы использовать встроенный Highlighter (основанный на highlight.js), я написал свой, с генерацией подсветки синтаксиса в процессе компиляции (основано на Highlight.java);
- дополнительные фичи использования полноценной компиляции (например, проверка всех ссылок на работоспособность).
Если интересует, как это выглядит, вот ссылка на мою последнюю статью сделанную с помощью Scalateχ: Running arbitrary containers in LinuxKit (ссылка на исходник в конце статьи).
Это уже зависит от конечного пользователя. Чтобы соответствовала семантика, можно просто применить стиль page-break-before для тега article. Но в целом: стили — CSS, контент — HTML.
Естественно, будет соблазн все понамешать, но это применимо для многих систем разметки: я видел, как и в LaTeX все в box-ы помещают, и в итоге код становится нечитабельным. А в том же Markdown уж слишком много ограничений и упрощений. В этом плане современный HTML с моей точки зрения — разумный компромисс (к тому же, это может быть просто промежуточный формат, как в моем случае).
Разве там есть теги для библиографии? глоссария? предметного указателя?
Типография — это все-таки немного другое. На Visual Basic наверное тоже можно написать систему управления банковскими транзакциями, но никто (я надеюсь?!) не делает этого. Правда, справедливости ради, отмечу, что HTML содержит все нужные теги (с точки зрения семантики, а не конечного оформления):
a— ссылки (соответственно, по ним формируется библиография, но конечно, нужна постобработка);dfn— термины (соответственно, глоссарий);- предметный указатель — это использование того же тега
a, но только в другом контексте — как якорь.
Ну и плюс к тому же, никто не мешает использовать собственные теги. Вопрос в использовании — когда уже есть готовые инструменты, незачем городить огород. Естественно, с чистого HTML книгу не сверстаешь, для этого есть другие, более подходящие форматы (и соответствующие инструменты).
книги и вёрстка тут ни при чём, например научные статьи также принято делать с библиографией т.е. есть такие семантические понятия — библиографическая ссылка, библиография и т.д.
Да, кроме официальных тулсетов есть реализация AsciiDoc на Ruby: asciidoctor. Со сложными документами там пока неважно (приемлемый pdf получить можно, но гибкости в настройке не хватает), но гораздо проще в установке и использовании для простых целей (небольшие статьи, одностраничники, простые pdf)
Мне очень понравился reStructuredText.
Идея очень близка к markdown, тоже очень хорошо читается. По сравнению с markdown предоставляет больше возможностей. Из него легко делается latex, odt, html.
P.S. LaTeX есть очень интересная альтернатива ConTeXt. Это тоже набор макросов. Главное отличие: писать стили легко, очень легко, и (но) это надо делать самому. Не очень распространен, поэтому обмен с коллегами затруднен.
Я бы сказал так: штука может быть удобна для внутреннего использования.
Насколько я понимаю, у ConTeXt есть ряд ограничений:
- указатель может быть только один
- над микротипографикой не такой уж сильный контроль
- нет таких плюшек, как, например, библиография по российскому ГОСТу
Может быть, я ошибаюсь, но поскольку документация скудная, а количество пользователей невелико, то выбор его в качестве инструмента обрекает на самостоятельное изобретение костылей.
Я сразу скажу, я не большой специалист по ConTeXt. Чуть-чуть покопался, но не серьезно.
Есть две нетехнические вещи, которые меня в нем настораживают:
- скудная документация и отсутствие «комьюнити»;
- система развивается только одной компанией, она может в любой момент закрыться.
По поводу библиографии. Насколько я понимаю, считается, что пользователь сам может сделать то, что ему надо (помните, стили писать легко, но вы должны сделать это сами).
Я за ConTeXt не агитирую. Вещь специфическая, со многими недостатками. Просто написал, что есть такое.
Знаю, что есть люди, которые пользуются, которым нравится. Поэтому упомянул, может кому пригодится.
А почему все так привязаны к PDF? Мне кажется, что жёстким форматам вёрстки, заточенным для печати, пора на покой. Читать двухколоночный текст даже с лопатофона совсем не удобно. Можно сделать «ревёрстку», в том же акробат ридере, но она часто отрабатывает с ошибками. В качестве конечного формата идеален HTML, его производные и аналоги, вроде CHM, FB2 и EPUB. Формулы — в MathML. Это, однако, стратегический вопрос и он регулируется издательской индустрией. Как только могучие научные издательства начнут переходить на семантически ориентированные форматы, PDF ждёт участь DJVU — формата для хранения памятников эпохи печати.
Если же вспоминать вообще о разных вариантах, ещё я бы добавил про разметку MediaWiki — внутренняя разметка для страниц Википедии.
Несмотря на то что это стандарт и стандарт который развивается уже давно, там тоже есть недоделки, например я столкнулся что в библиографии не предусмотрен тег для url источника
Все там есть. Просто в DocBook'e нужно именно сидеть и вдумчиво разбираться. Касательно ссылки — это не тег, а атрибут для biblioentry. Если говорить про DocBook 5.1. А для 4.5 можно какой нибудь ulink использовать. Вся прелесть в том, что схему можно полностью перекроить под себя, при необходимости. Особенно это касается 5.0 и 5.1, т.к. там перешли от DTD к RelaxNG схемам.
А вообще, по сабжу — всерьез можно говорить только DITA и DocBook. Первая технология больше подходит для контекстных топиков, вторая — для больших книг. Впрочем, 5я версия DocBook сильно вильнула в сторону топико-ориентированности. Все остальное с точки зрения авторинга — так себе технологии.
Что касается GUI — Oxygen наше все. Там и докбук, и дита из коробки — пиши да публикуй. А если ты еще и в XSLT волокешь, то вообще никаких проблем не будет все это кастомизировать под свои нужды. Вон, люди умудряются доки по стандартам ЕСПД/ЕСКД выпускать в докбуке. И нет там ничего секретного.
а можно ссылку, я на 5.0 смотрел, ща глянул в 5.1 — не нахожу такого атрибута, да и это не может быть атрибутом, это должен быть тэг
<biblioentry>
<citetitle pubwork="book">
<link xlink:href="http://....."></link>
</citetitle>
</biblioentry>
В biblioentry есть точно такой же, кстати, атрибут xlink:href.
Немного промахнулся с ответом…
Т.к. URL не является единственным возможным видом ресурса.
Для URL конструкция будет иметь вид:
...
<bibliosource class="uri">
<link href="..."/>
</bibliosource>
...
Семантическая разметка: LaTeX, DocBook или ???