[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK-APPS: No callout numbers in the code with programlistingco
I am working on a pretty big project to convert a large documentation base over to DocBook, and it's my responsibility to figure out what works and what doesn't when transforming the DocBook 4.1 code into a rendered format. Thus far, my biggest problem has been with <programlistingco> not showing the callout numbers in line with the code. The callouts that come after the <programlisting> block work fine, but no matter how I transform the original DocBook, there are never corresponding numbers in the code. I have a feeling that something is wrong with some part of the software I am using, but I do not know what. In the archives for this list, I found a message where Norman Walsh posted code along with rendered documents where the use of <programlistingco> worked quite well. (The message is http://lists.oasis-open.org/archives/docbook-apps/200103/msg00337.html.) When I try to run FOP 0.20.3rc on the included cotest.xml, I get no callout numbers with the code. The same is true if I run xsltproc to generate FO for XEP or to generate HTML. In other words, using the same source XML file, I get different results than Norman. The relevant versions of software I am using are as follows: * libxslt 1.0.12 (compiled against libxml2 2.4.15) * FOP 0.20.3rc * docbook-xsl-1.48 * docbook-dsssl-1.74b Is there some step I am forgetting? Is there a better XSLT tool than xsltproc from libxslt to use? I've attached the offending use of <programlistingco> in case it might provide some other useful information. Thanks. -Patrick -- Patrick L. Hartling | Research Assistant, VRAC patrick@vrac.iastate.edu | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/
<?xml version='1.0'?> <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> <chapter> <title>Test</title> <programlistingco> <areaspec> <area coords="5" id="simpleApp.main.body.create-kernel"/> <area coords="6" id="simpleApp.main.body.app-instantiate"/> <area coords="8" id="simpleApp.main.body.loadConfigFile"/> <area coords="9" id="simpleApp.main.body.start"/> <area coords="10" id="simpleApp.main.body.setApp"/> </areaspec> <programlisting linenumbering="numbered">#include <simpleApp.h> int main (int argc, char* argv[]) { vjKernel* kernel = vjKernel::instance(); // Get the kernel simpleApp* app = new simpleApp(); // Create the app object kernel->loadConfigFile(...); // Configure the kernel kernel->start(); // Start the kernel thread kernel->setApplication(app); // Give application to kernel while ( ! exit ) { // sleep } }</programlisting> <calloutlist> <callout arearefs="simpleApp.main.body.create-kernel"> <para>This line finds (and may create) the VR Juggler kernel. The kernel reference is stored in the handle so that we can use it later.</para> </callout> <callout arearefs="simpleApp.main.body.app-instantiate"> <para>We instantiate a copy of the user application object (simpleApp) here. Notice that we include the header file that defines the simpleApp class.</para> </callout> <callout arearefs="simpleApp.main.body.loadConfigFile"> <para>This statement represents the code that will be in the <function>main()</function> function for passing configuration files to the kernel's loadConfigFile() method. These config files may come from the command line or some other source. If reading the files from the command line, it can be as simple as looping through all the arguments and passing each one to the kernel.</para> </callout> <callout arearefs="simpleApp.main.body.start"> <para>As a result of this statement, the VR Juggler kernel begins running. It creates a new thread of execution for the kernel, and the kernel begins its internal processing. From this point on, any changes made reconfigure the kernel. These changes can come in the form of more configuration files or in the form of an application object to execute.At this point, it is important to notice that the kernel knows nothing about the application. Moreover, it needs to know nothing about the configuration files either. This demonstrates how the VR Juggler kernel executes independently from the user application. The kernel will simply work on its own controlling and configuring the system even without an application to run.</para> </callout> <callout arearefs="simpleApp.main.body.setApp"> <para>This statement finally tells the kernel what application it should run. The method call reconfigures the kernel so that it will now start invoking the application object's member functions. It is at this time that the application is now running in the VR system.</para> </callout> </calloutlist> </programlistingco> </chapter>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC