This version should not be present here.....if the LFS folk wish to contribute
it, then, it should go right on top of the older version. I did not want to
make that choice for them, but having the duplicate here is also not good, so
I'm removing it.
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
It is not valid to have <indexterm/> elements directly as a child of a
<varlistentry/>, so I have moved them inside the <listitem/>. I tried putting
them inbetween <varlistentry/> elements (no good).
there were two locations where CDATA was outside of an enclosing </para> or
inside another element that could not contain it (according to the DocBook XML
element nesting model).
An <abstract/> element can contain a <para/>, which can contain an
<itemizedlist/>, but the <itemizedlist/> may not be a direct child of an
<abstract/>.
there was a mismatch between the root element and the doctype declaration;
assuming that the root element is correct, synchronizing these two changes
fixed the validation problems
the doctype declaration had conflicting entries; the public identifier said
4.1.2 and the system identifier said 4.0; I would not have noticed this,
except that xmllint was complaining about the <author/> element containing an
<email/> (invalid!)
this was easily resolved by changing the version of this document to be a
DocBook XML 4.2 document
Move the <?dbhtml filename="glossary"?> to its correct location after the
opening <glossary> tag; otherwise the index.html file gets named
glossary.html (oops!).
Generating PDF outputs (today), requires using <mediaobject> and supplying a
file that can be converted into a print-consumable by the TeX engine.
I added .eps files (thank you, ImageMagick) to allow regeneration and also
added a file called 'image-missing' for the peculiar absence of a file
called OREILLY.BIND.DIAGRAM.
Below comment is reproduced in the doc-index.sgml, which
was generated using collateindex.pl and then hand-tuned into
valid DocBook SGML (version 3.1).
The stock collateindex.pl (md5=2e36626ed6709e5ba0e6af0999bc3102, in
dsssl-stylesheets-1.79) program makes a few mistakes in generating
the complex index below.
It creates a nesting problem for <secondaryie/> elements which contain
both a <ulink/> and have a subsequent <seeie/>. In that case, it
orphans the <ulink/> elements beneath the <seeie/> AFTER closing the
<secondaryie/>. I can't figure out a patch to collateindex.pl, so
hand-fixed the 5 entries and am committing this as is for TLDP.
The qandaset had a defaultlabel="none" attribute. This is DocBook legal, but
the XSLT layer was producing FO output that included an empty
fo:list-item-label, with the following error message:
"fo:list-item-label" is missing child elements. Required content model:
marker* (%block;)+
By omitting the defaultlabel="none", the entire problem disappears.
Also, adjusted paths for reference to the ./Annimals/ which are now in
./resources/Annimals/.
The images were supplied here as a tarball, which meant that the DocBook
processor could not read them directly out of the version control system;
adding directories for the ./images/ and the ./resources/ (which contains
Annimals subdirectory and one chap4sec26 file.
first, xsltproc (and friends) did not like the duplication of id="A" in both
the gloss.xml and index-gloss.xml; so renaming the IDs solved that problem
second, fop complained that empty gloss entries existed; no problem after
commenting them out
There was a bare ampersand in a <title/>, replaced with &
Quite a few <programlisting/> elements also contained bare ampersands, so
each <programlisting/> earned a child element of <![CDATA[]]>
One <parameter/> element lacked quotations on the value for its
class attribute. Corrected.
xsltproc and friends will happily generate the index in one
pass, obviating the need for the separate index.xml file, which
must be generated using the jade toolchain; thus commenting out
the (missing) external index and generating it on the fly;
N.B. there were only two </indexterm> entries in the document, but
at least they were present
The <emphasis/> tag cannot live inside a <systemitem/> or a <literal/>, but
it can certainly surround these elements; inverting to allow for validation
and processing.
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;