files were declared with <?xml version="1.0" encoding="UTF-8"?>
but were definitely not UTF-8; corrected and added Unicode BOM
Linux-Networking.xml: fixed a doubly-closed </ulink>
Overview.xml: there were several large pasted sections of text which
contained characters understood to be markup; wrapped the entire
sections in <![CDATA[ ]]> blocks;
Protocols-Standards-Services.xml: closing </sect1> tags cannot have id="" on
them: removed these; wrapped several email addresses with <email/> to allow
validation; fixed tons of URLs with proper <ulink/> elements; wrapped a few
pasted sections in <![CDATA[ ]]> blocks;
jade processor was very unhappy to have closing tags on <imagedata>;
removing them (which felt like violence) allowed the document to be
validated and processed
In his document build system, each script is cooked (wrapped in <![ CDATA []]>
during build process--this is elegant, but we are not calling his build
Makefile, so we need to store the cooked scripts in the source tree.
jade did not like trying to process <graphic/> elements where it could not
find the source images; also, it wanted the filename extension included (did
early DocBook SGML processing tools simply locate an image of the preferred
type?)
Commented out an <inlinemediaobject/> which was using processing instructions
(IGNORE/INCLUDE) to control selection of several <imageobject/> children and
one <textobject/> child; jade got confused because there was no <imageobject/>
being selected, only a <textobject/> so refused to process the document
Also, cleaned up some stray </listitem> and missing <emphasis> elements
throughout the document. Squashed one stray </chapter> ending the
bibliography and removed an attribute (title=) that was forbidden on a
<bibliography/> element.
The DOCTYPE specification was missing the System Identifier
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"
Processing is still not validating properly, because the toolchain used to
generate this, before, created the index.xml file on a first pass, and then
the actual document on the second pass, in the style of SGML tools.
I would like to figure out how to support both with a processing instruction.
Georg Käfer had to become Georg Käfer for SGML, anyway; the
problem was not in the generation of HTML, but rather PDF output
through the tex engine
changing all <link xlink:href=""/> elements to <ulink url=""/>;
this document is DocBook 4.1.2, and the use of xlink:href="" instead of the
more general <ulink/> element was preventing proper processing of the
document (without making the processor aware of this particular namespace)
HOWTO can be processed now by a completely automated (xsltproc) toolchain.
Martin A. Brown