The LDP output tree has an inconsistent structure for handling documents of
different types. With the new processing tools, we will be able to produce
a single output directory for each source document. This script allows
the creation of links in the historical LDP output directory to the new
automatically created (and updated) directory.
This document used an endterm in the wrong place and its presence was
confusing the heck out of the FO processor:
<xref endterm="partitiontable" linkend="partitiontable" />
The endterm="" attribute tells the DocBook processor to copy the content found
at the linkend inline. The problem is that the content at this particular
linkend was an entire table. This meant that the FO processor was receiving
an entire (DocBook) table (as FO, of course) and futilely trying to render it
inline.
Removing the endterm="partitiontable" allows the document to be processed by
FOP into a PDF.
Author contacted, responded quickly, provided the missing old files
and confirmed that it was acceptable to comment out the reference to
../openMosix-2.6-HOWTO/openMosix-2.6-HOWTO-content.sgml
Source available: https://github.com/KrisBuytaert/openmosix-howto
Author contacted, responded quickly, provided the missing old files
and confirmed that it was acceptable to comment out the reference to
../openMosix-2.6-HOWTO/openMosix-2.6-HOWTO-content.sgml
Source available: https://github.com/KrisBuytaert/openmosix-howto
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 desired output formats can be tweaked by setting the value of the
parameter entities %output.print.png% (and friends) to "INCLUDE";
The document still needed a few corrections, namely the removal of two
extraneous </listitem> elements and a few <application/> and <acronym/>
elements that were in illegal locations (for example as a child of the
<contrib> element).