This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 &lt;simpleApp.h&gt;

int main (int argc, char* argv[])
{
   vjKernel* kernel = vjKernel::instance();  // Get the kernel
   simpleApp* app   = new simpleApp();       // Create the app object

   kernel-&gt;loadConfigFile(...);              // Configure the kernel
   kernel-&gt;start();                          // Start the kernel thread
   kernel-&gt;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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]