For elements that should behave like sections (for now, mostly prefaces).
A second paragraph of PartBacktext can only wreak havok: it should start a section, and nothing else (otherwise, it's a real nightmare to implement).
It's invalid to have an <inlineequation> outside a paragraph. Another solution would have been to change InsetMathHull::docbook to generate an <informalequation>, but that function would have required more knowledge about its context than now.
Need more tests to determine if <inlineequation> should only be output for hullSimple or in more cases like:
const static std::set<HullType> inlineHulls = {
hullUnknown,
hullNone,
hullSimple,
hullEquation,
hullMultline,
hullGather,
hullRegexp
};
This ensures that all comparisons for DocBook are made on the same normalised version of the float type. This cased a strange bug where <table> was output within <informaltable> for Linguistics Tableaux.
This is a minimal implementation, as DocBook lacks a serious way of encoding all of this. Maybe a <formalpara> could do the trick, but I'd need to find a way to shoehorn a title through the styles (i.e. a first complete tag):
Theorem: Bla bla
<formalpara>
<title>Theorem</title>
<para>Bla bla</para>
</formalpara>
This would also only be a solution for single-paragraph things, as formalpara only allows one paragraph. Or a sidebar, but it's semantically very remote.
Includes: semantic markup (sorry about noun: Additional.lyx uses it to mark menus; there is something better in DocBook, but it looks like the LaTeX equivalent is really for person names), boxes, info layouts.
Actually output something when list item is empty. XMLStream discarded the sequence StartTag/EndTag (nothing in between).
New-line behaviour around term in description lists.
That's mostly generating DocBook tags at an inappropriate place with some metadata, rather than outputting whatever you have at your disposal. Far from satisfying, but good enough for a generic tool (see details in the new TODO). Doesn't trigger assertions. Is valid XML.
Before, it directly wrote to the XMLStream, but it made implementation of new lines tricky. Now, it returns the XML for each sub-paragraph (delimited by new lines) as a string, so that the caller can adopt a more precise behaviour (such as in lists).
