refdb-users — List for RefDB users

Re: [Refdb-users] refdb-users archive

[Marc H. <mar...@en...>]

On Tue, 9 Mar 2004, David Nebauer wrote:

> Has anybody else noticed that messages to the refdb-users list have
> stopped appearing on the archive page
> <http://sourceforge.net/mailarchive/forum.php?forum=refdb-users>?  The
> latest message there is in the "User feedback 1" thread and is
> timestamped "2004-03-03 03:03" (hmm, accidental alliteration).
>
> My experience has been that messages appeared on the archive page pretty
> much at the time they were received by the list.  I suspect this change
> in behaviour may not be normal.

My experience (on last months) has rather been the opposite:  quite
frequent lags. But I won't argue I consider this as "normal".

[Refdb-users] refdb-users archive

[David N. <dav...@bi...>]

Hi all,

Has anybody else noticed that messages to the refdb-users list have 
stopped appearing on the archive page 
<http://sourceforge.net/mailarchive/forum.php?forum=refdb-users>?  The 
latest message there is in the "User feedback 1" thread and is 
timestamped "2004-03-03 03:03" (hmm, accidental alliteration).

My experience has been that messages appeared on the archive page pretty 
much at the time they were received by the list.  I suspect this change 
in behaviour may not be normal.

Regards,
David.

Re: [Refdb-users] FO stylesheet problem #2: docbook xml book converts to invalid FO

[David N. <dav...@bi...>]

Hi Markus,

>David Nebauer writes:
> > I guess that leaves us with the third option of a stylesheet version
> > mismatch.
> > 
>
>I've tried this option and updated the stylesheet code to match the
>current DocBook-xsl verison 1.65.0. Seems to work alright now. I've
>checked in the updated version (1.5). I've also sent you a copy by
>private mail. Please try and see whether it fixes your problems as
>well.
>  
>

That certainly fixed the problem of the docbookx book not printing, 
which refdb is now doing just fine.

Amazingly, it also fixed the duplicate "Reference List" bug!

At this point every one of my major concerns has been met, and very 
promptly too.  Thanks for all your help.  For what it's worth, I now 
have a fully functional XML to PDF/HTML toolchain with full 
bibliographic support.  I don't know what inspired you to embark on the 
refdb project, or keeps you going, but long may it do so.

Time to tackle CVS and download an up-to-date version with all the 
changes rolled in.

Regards,
David.

Re: [Refdb-users] FO stylesheet problem #2: docbook xml book converts to invalid FO

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > I guess that leaves us with the third option of a stylesheet version
 > mismatch.
 > 

I've tried this option and updated the stylesheet code to match the
current DocBook-xsl verison 1.65.0. Seems to work alright now. I've
checked in the updated version (1.5). I've also sent you a copy by
private mail. Please try and see whether it fixes your problems as
well.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] perl script

[Bruce D'A. <bd...@fa...>]

Can someone with some Perl skills help me modify this script?

http://www.macdevcenter.com/mac/2004/03/05/examples/watch.pl

Currently it watches a tex file, and compiles it if it's updated.

I want to modify it to do the following:

Watch an xml file instead.  When changed, run an xslt on the file, 
*then* run that output through pdflatex.

Thanks,
Bruce

Re: [Refdb-users] FO stylesheet problem #1: duplicate 'Reference List' text

[David N. <dav...@bi...>]

Hi Markus,

<quote who="Markus Hoenicka">
> David Nebauer writes:
>  > The FO is simply hideous to read in plain text, but the relevant
> portion  is: <fo:block [... lots of attributes ...]>Reference
>  > List</fo:block></fo:block></fo:block><fo:block/></fo:block>Reference
> List<fo:block ...

> BTW trying to
> suppress the bib title in the driver file does not help either.

I also tried fiddling with those lines (31 and 62 in the refdb fo driver
file, if memory serves).  Removing one or both of them resulted in either
no change or no "Reference List" heading at all (but the "Reference List"
outside the fo:block still appeared).

Hope you're able to debug this problem.  It is the sole remaining obstacle
to refdb docbookx article output -- and the last bugs are always the
hardest to squash!

Regards,
David.

Re: [Refdb-users] FO stylesheet problem #2: docbook xml book converts to invalid FO

[David N. <dav...@bi...>]

Hi Markus,

<quote who="Markus Hoenicka">
> David Nebauer writes:
>  > Since the source file converts to html perfectly the problem appears
> to  lie with the refdb fo stylesheets.  Since docbook xml articles do
> not  appear to produce the same error, it involves something specific
> to  docbookx books -- or at least not affecting docbookx articles.
> Once  again, however, I am insufficiently knowledgeable about xsl
> (and fo) to  determine the cause of the problem.
>
> Second, you could attempt to process the document using the stock
> DocBook stylesheets. The result will be more than ugly, but this could
> help to isolate the problem. If the RefDB driver files are the
> culprit, the DocBook fo stylesheets should transform the document
> without errors, regardless of how nasty the output is going to look.

I didn't mention it in my message, but I did process the <filename>.xml,
file produced by refdbxml, using the stock docbookx stylesheets.  It
transformed the document into valid FO and subsequently to valid PDF. 
Although it was, as you say, more than ugly.

I guess that leaves us with the third option of a stylesheet version
mismatch.

It's so frustrating to have a workable toolchain just out of reach...

I'll keep prodding away at the problem, but for now it's beyond my skill
level to debug.

Regards,
David.

[Refdb-users] FO stylesheet problem #2: docbook xml book converts to invalid FO

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > Since the source file converts to html perfectly the problem appears to 
 > lie with the refdb fo stylesheets.  Since docbook xml articles do not 
 > appear to produce the same error, it involves something specific to 
 > docbookx books -- or at least not affecting docbookx articles.  Once 
 > again, however, I am insufficiently knowledgeable about xsl (and fo) to 
 > determine the cause of the problem.
 > 

There's a few things we can do to address this problem. First of all,
your hand-coded test document #1 does not contain a bibliography. I
don't expect this to be the reason, but you should probably provide a
hand-coded bibliography to test the stock DocBook stylesheet
bibliography code.

Second, you could attempt to process the document using the stock
DocBook stylesheets. The result will be more than ugly, but this could
help to isolate the problem. If the RefDB driver files are the
culprit, the DocBook fo stylesheets should transform the document
without errors, regardless of how nasty the output is going to look.

Third, I suspect that a version mismatch might cause the problem. In
contrast to the more or less static DSSSL stylesheets, the XSLT
stylesheets have changed quite a bit since I implemented the RefDB
driver files. It is quite likely that the templates that the driver
files override have to be updated to a recent version of the stock
DocBook stylesheets. I'll try to find some time next week to look into
this.

In general, the bibliography code in the fo stylesheets is a lot more
complex than in the html stylesheets, as it has to take care of things
like recto/verso, proper pagination and such. Therefore it is not
surprising that it is easier to confuse than the html output.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] FO stylesheet problem #1: duplicate "Reference List" text

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > The FO is simply hideous to read in plain text, but the relevant portion 
 > is: <fo:block [... lots of attributes ...]>Reference 
 > List</fo:block></fo:block></fo:block><fo:block/></fo:block>Reference 
 > List<fo:block ...
 > 

I'm at a loss here. This is a long-standing bug in the printable
output from XML. The RefDB driver files do not render the bibliography
title directly. The DocBook stylesheets actually suppress direct
rendering of the bibliography title as this is handled by the
bibliography page code. What strikes me most is that the second
appearance of the bibliography title occurs outside of any fo:block
element. It looks like it slips in accidentally. BTW trying to
suppress the bib title in the driver file does not help either.

Now that I can use FOP to get printable output, I'll investigate what
causes this problem. However, I'm not an XSLT guru, so any help would
be greatly appreciated.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-users] FO stylesheet problem #2: docbook xml book converts to invalid FO

[David N. <dav...@bi...>]

Hi all,

I've just attempted for the first time to produce pdf output from a 
docbook xml book (my previous efforts being with docbook xml _articles_).

Here is the basic document, without any refdb features:
........................................................................................
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<book>
    <bookinfo>
        <title>Test of Reference Name</title>
        <author>
            <surname>Nebauer</surname>
            <firstname>David</firstname>
        </author>
    </bookinfo>
    <chapter id="bogus">
        <title>Bogus Reference</title>
        <para>Here's a reference to [... citation here ...] involve the 
refdb machinery.</para>
    </chapter>
</book>
........................................................................................

This document easily converts to a 5-page pdf document with saxon and fop.

If I now add the bibliography entity declaration, a citation and the 
bibliography entity itself, I get the following document:
........................................................................................
<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY bibliography SYSTEM "bookref.bib.xml">
]>
<book>
    <bookinfo>
        <title>Test of Reference Name</title>
        <author>
            <surname>Nebauer</surname>
            <firstname>David</firstname>
        </author>
    </bookinfo>
    <chapter id="bogus">
        <title>Bogus Reference</title>
        <para>Here's a reference to <citation 
role="REFDB">lamport1994</citation> to involve the refdb machinery.</para>
    </chapter>
    &bibliography;
</book>
........................................................................................

Using the refdbnd Makefile to convert to pdf produces a valid .bib file:
........................................................................................
<!-- <?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" 
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"> -->
<bibliography role="refdb">
<title>Reference List</title>
<bibliomixed id="IDlamport1994" role="BOOK">
<bibliomset role="intext" id="IDlamport1994X">(<bibliomset 
relation="author"><surname>Lamport</surname></bibliomset>, <pubdate 
role="primary">1994</pubdate>)</bibliomset>
<bibliomset role="intextsq" id="IDlamport1994S">(<bibliomset 
relation="author"><surname>Lamport</surname></bibliomset>, <pubdate 
role="primary">1994</pubdate>)</bibliomset>
<bibliomset role="authoronly" id="IDlamport1994A"><bibliomset 
relation="author"><surname>Lamport</surname></bibliomset></bibliomset>
<bibliomset role="authoronlysq" id="IDlamport1994Q"><bibliomset 
relation="author"><surname>Lamport</surname></bibliomset></bibliomset>
<bibliomset role="yearonly" id="IDlamport1994Y">(<pubdate 
role="primary">1994</pubdate>)</bibliomset>
<bibliomset role="bibliography" id="IDlamport1994B"><bibliomset 
relation="book"><bibliomset relation="author"><surname>Lamport</surname> 
<firstname>L.</firstname></bibliomset>, </bibliomset><bibliomset 
relation="book"><pubdate role="primary">1994</pubdate>, 
</bibliomset><bibliomset relation="book"><title role="BOOK">LaTeX: A 
Document Preparation System</title> (</bibliomset><bibliomset 
relation="book"><publishername>Addison-Wesley</publishername>, 
</bibliomset><bibliomset 
relation="book"><address><city>Massachusetts</city></address>) 
</bibliomset></bibliomset></bibliomixed>
<bibliomixed role="multixref"></bibliomixed></bibliography>
........................................................................................

It produces an FO file, but that file is not valid.  Neither passivetex, 
fop or xep would convert it to pdf.  passivetex became terminally 
confused and produced gibberish.  Here are the error messages for fop 
and xep:

FOP:
........................................................................................
[ERROR] 
file:/home/david/data/computing/docbook-xml/learn/bookref/bookref.fo:2:56273 
master-reference '' for fo:page-sequence matches no simple-page-master 
or page-sequence-master
........................................................................................

XEP:
........................................................................................
(document [system-id 
file:/home/david/data/computing/docbook-xml/learn/bookref/bookref.fo]
  (validate
    [error] 
file:/home/david/data/computing/docbook-xml/learn/bookref/bookref.fo: 
line 2: Attribute 'master-name' cannot occur at element 'fo:page-sequence'.
    [error] 
file:/home/david/data/computing/docbook-xml/learn/bookref/bookref.fo: 
line 2: Attribute 'master-reference' is required for 'fo:page-sequence'.
    [validation total: 2 errors]
Parse error: Invalid XSL FO source 
'file:/home/david/data/computing/docbook-xml/learn/bookref/bookref.fo': 
2 error(s) found during validation
.........................................................................................

Both of them are complaining about the same error: an illegal attribute 
('master-name') in element 'fo:page-sequence'.  xep also thinks a 
required attribute ('master-reference') is missing from the same element.

Here is the offending bit of the FO file.  Look for the 
<fo:page-sequence id="id2562418" ...> element and see the master-name 
attribute.  I have added some context to show that this element occurs 
in the FO file after the main text and before the reference list 
heading.  You can also see the duplication of the text: "Reference List".
........................................................................................................
Here's a reference to <fo:basic-link 
internal-destination="IDlamport1994">(Lamport, 1994)</fo:basic-link> to 
involve the refdb 
machinery.</fo:block></fo:flow></fo:page-sequence><fo:page-sequence 
id="id2562418" hyphenate="true" master-name="back" language="en"> [... 
snip ...] <fo:block>Reference List</fo:block> [... snip 
...]<fo:block>Reference List</fo:block> [... snip ...] <fo:block 
id="IDlamport1994" space-before.optimum="1em" 
space-before.minimum="0.8em" space-before.maximum="1.2em">Lamport L., 
1994, LaTeX: A Document Preparation System (Addison-Wesley, 
Massachusetts) </fo:block>
........................................................................................................

This error occurs with both saxon-xerces and xsltproc, which would seem 
to rule out an xslt processor-specific bug.

Since the source file converts to html perfectly the problem appears to 
lie with the refdb fo stylesheets.  Since docbook xml articles do not 
appear to produce the same error, it involves something specific to 
docbookx books -- or at least not affecting docbookx articles.  Once 
again, however, I am insufficiently knowledgeable about xsl (and fo) to 
determine the cause of the problem.

Does anybody have an idea what is happening here?  Has anyone ever 
produced a pdf file from a docbook xml book using refdb?

Regards,
David.

[Refdb-users] FO stylesheet problem #1: duplicate "Reference List" text

[David N. <dav...@bi...>]

Hi all,

When producing pdf output from a docbook xml article, the text 
"Reference List" is duplicated immediately after the "Reference List" 
heading.

Here is the xml source file:
..........................................................................................
<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY bibliography SYSTEM "reftoc.bib.xml">
]>
<article>

[... snip ...]

<para>My current working theory is that it wil be absent in simple 
documents.  This document is a test of that theory.  So, here goes 
&hellip;</para>
    </section>
    &bibliography;
</article>
...........................................................................................

After tranformation to FO, the last part of the .fo file reads:

...........................................................................................
My current working theory is that it wil be absent in simple documents.  
This doument is a test of that theory.  So, here goes 
&#x2026;</fo:block></fo:block><fo:block 
id="id2514948"><fo:block><fo:block><fo:block margin-left="-4pc" 
font-size="24.8832pt" font-family="sans-serif,Symbol,ZapfDingbats" 
font-weight="bold"><fo:block keep-with-next.within-column="always" 
space-before.optimum="10pt" space-before.minimum="8pt" 
space-before.maximum="12pt" hyphenate="false" hyphenation-character="-" 
hyphenation-push-character-count="2" 
hyphenation-remain-character-count="2">Reference 
List</fo:block></fo:block></fo:block><fo:block/></fo:block>Reference 
List<fo:block id="IDlamport1994" space-before.optimum="1em" 
space-before.minimum="0.8em" space-before.maximum="1.2em">Lamport L., 
1994, LaTeX: A Document Preparation System (Addison-Wesley, 
Massachusetts) </fo:block><fo:block id="IDsavitch2001" 
space-before.optimum="1em" space-before.minimum="0.8em" 
space-before.maximum="1.2em">Savitch W., 2001, Java: An Introduction to 
Computer Science (Prentice Hall, New Jersey) </fo:block><fo:block 
id="id2575077" space-before.optimum="1em" space-before.minimum="0.8em" 
space-before.maximum="1.2em"/></fo:block></fo:flow></fo:page-sequence></fo:root>
...........................................................................................

The FO is simply hideous to read in plain text, but the relevant portion 
is: <fo:block [... lots of attributes ...]>Reference 
List</fo:block></fo:block></fo:block><fo:block/></fo:block>Reference 
List<fo:block ...

You can see that the text does, in fact, appear again after the heading.

This does not occur with html output.  It appears to be an artefact 
caused by the refdb FO stylesheets.

I've attempted to delve into the stylesheets but am only beginning to 
fathom xsl.  If there's anyone out there who can help solve this 
problem, I'll do all I can to assist.

Regards,
David.

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Hi Markus,

>Do you have the classpaths for all the Java apps handy? I'd like to
>add example classpaths for each processor to the refdbxmlrc config
>file.
>

Here we go.  I'm going to include some comments and write the whole 
thing as if the reader is a relative newcomer to *nix who knows just 
enough to install software, create symlinks and manipulate files.  Where 
available, I'll indicate relevant Debian packages.

...................................................................................

In these examples, version numbers are often left out of jar file names, 
eg. logkit-1.1.jar would be logkit.jar.  The short form is a symlink to 
the longer titled file.  This can be done by the installation script or 
by the user.

In example classpaths, each component is put on a separate line for 
clarity.  When creating your own classpath, do not use line breaks, 
continuation marks ("\") or whitespace (tabs or spaces).

Instructions for xalan, saxon, saxon-xerces and fop are largely based on 
Bob Stayton's "DocBook XSL: The Complete Guide", Chapter 3 (Getting the 
tools working), see <http://www.sagehill.net/docbookxsl/index.html>.


xalan
    requires: xalan2.jar

    xalan2.jar
          - Important: this is the docbook stylesheets extension version
          - look for it in 'extensions' directory of docbook xsl stylesheets
          - debian package: docbook-xsl

    example classpath
          
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/xalan2.jar


saxon
    requires: saxon.jar, saxonXXX.jar, resolver.jar, (directory: user 
catalogs)

    saxon.jar
          - debian package: lib-saxon-java
    saxonXXX.jar  (where 'XXX' is version number)
          - docbook stylesheet saxon extension
          - found in 'extensions' subdirectory of docbook xsl stylesheets
          - use jar with closest match to saxon version, eg. for saxon 
version 6.4.4-1 use saxon644.jar
          - debian package: docbook-xsl
    resolver.jar
          - Apache project's catalog resolver
          - debian package:  xml-commons-resolver
    (directory: user catalogs)
          - when using catalogs, saxon needs to find a file called 
'Catalog.properties' on the classpath
          - include directory containing 'Catalog.properties' file
          - see saxon documentation for further details
  
    example classpath:
            /usr/share/java/saxon.jar:\
            
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/saxon644.jar:\
            /usr/share/java/resolver.jar:\
            /home/user/xml/catalogs/


saxon-xerces
    requires: as per 'saxon' PLUS xercesImpl.jar

    xercesImpl.jar
          - Apache's Xerces XML parser
          - debian package: libxerces2-java

    example classpath:
            /usr/share/java/saxon.jar:\
            
/usr/share/sgml/docbook/stylesheet/xsl/nwalsh/extensions/saxon644.jar:\
            /usr/share/java/resolver.jar:\
            /usr/share/java/xercesImpl.jar:\
            /home/user/xml/catalogs/


xt
    requires: xt.jar, xp.jar

    xt.jar
          - James Clark's XSLT transformer
          - debian package: libxt-java
    xp.jar
          - James Clark's XML parser
          - debian package: none.  Download from 
<http://www.jclark.com/xml/xp/>

    example classpath:
          /usr/share/java/xt.jar:\
          /usr/share/java/xp.jar


fop
    requires: fop.jar, batik.jar, xercesImpl.jar, avalon-framework.jar

    fop.jar
          - base fop package
    batik.jar
          - fop support package
    xercesImpl.jar
          - xml parser packaged with fop
    avalon-framework.jar
          - fop support package
    (all .jar files)
          - debian package: none, all are part of fop binary distribution
          - download from <http://xml.apache.org/fop/>

    example classpath:
            /usr/local/java/fop/build/fop.jar:\
            /usr/local/java/fop/lib/batik.jar:\
            /usr/local/java/fop/lib/xercesImpl-2.2.1.jar:\
            /usr/local/java/fop/lib/avalon-framework-cvs-20020806.jar


jfor
    requires: jfor.jar, xerces.jar, logkit.jar

    jfor.jar
          - jfor base package
          - debian package: none.  Download from 
<http://sourceforge.net/projects/jfor>
    xerces.jar
          - Apache's xml parser
          - debian package: libxerces-java
    logkit.jar
          - Apache application logger
          - debian package: liblogkit-java

    example classpath:
          /usr/share/java/jfor.jar:\
          /usr/share/java/xerces.jar:\
          /usr/share/java/logkit.jar
   
...............................................................................................................

Take whatever you think appropriate.

Regards,
David.

Re: [Refdb-users] User feedback 3

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > I've now tested the Makefile against my new refdbxml and refdbxmlrc 
 > files using all the xslt and fo processors included to date.
 > 
 > This includes: xalan, xt, saxon, saxon-xerces, xsltproc, passivetex, 
 > fop, xep and jfor.
 > 

Do you have the classpaths for all the Java apps handy? I'd like to
add example classpaths for each processor to the refdbxmlrc config
file.


 > The only thing still bugging me is the theoretical possibility of 
 > invoking refdbxml with a mismatch between the fo processor and output 
 > type (eg. jfor processor with pdf output).  Something like the following 
 > code could be inserted at the start of process_print:
 > 

I've added that too.

 > Other than that, I think it might do for now :-) .
 > 

If you think so... Thanks a lot for your work.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] User feedback 3

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
 > [ ! $fo_processor = "xep" ] && [ ! $fo_processor = "jfor" ]; then
 >                                                                                                    
 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >   echo "specify one of 'passivetex', 'fop', 'xep', 'jfor' with the -f 
 > option"
 >                                                  ^^^^^^^^

Ok, I've fixed these lines.

 > # Set classpath variables to default if not already specified
 > if ! [ -n "$xslt_classpath" ]; then
 >                  ^^^^^^^^^
 >     xslt_classpath=$classpath
 >          ^^^^^^^^^
 > fi
 > if ! [ -n "$fo_classpath" ]; then
 >                ^^^^^^^^^
 >     fo_classpath=$classpath
 >        ^^^^^^^^^
 > fi

These were the "obvious typos"...

 > process_print () {
 >     case $fo_processor in
 >     jfor )
 >         java -cp "$fo_classpath" 
 > ch.codeconsult.jfor.main.CmdLineConverter $1 $2;;
 >                    ^^^

I've fixed this as well.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] User feedback 3

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > Providing xep.sh is on the system path, xep can be invoked in 
 > process_print thus:
 > 
 >     xep.sh -fo $1 -pdf $2
 > 
 > This would remove the need to specify xep's root directory.
 > 
 > The only potential problem is that the installer does not place xep.sh 
 > in a standard system directory, like /usr/local/bin or /usr/bin.  IMO, 
 > however, that can rightfully be considered part of the xep install 
 > process rather than part of the refdb configure process.  If you changed 
 > the xep launch command to use xep.sh, perhaps a note in the init file 
 > could indicate the need to make sure xep.sh is on the system path?
 > 

I've changed refdbxml to use xep.sh. The full path can be set at the
top of the file. By default the variable is empty, i.e. xep.sh is
searched for in your PATH. The simplest way to get xep.sh into your
PATH (for all users) may be to create a symlink in /usr/local/bin.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Hi Markus,

>Hi David,
>
>David Nebauer writes:
> > At the end of this message please find:
> > 1. An init file for refdbxml: refdbxmlrc
> > 2. A re-written refdbxml to use the init file
> > 
>
>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable. I've
>tested the updated script with xsltproc and FOP. I'm currently
>updating my xerces and Saxon installations, but I expect this will
>work too.
>  
>

I've now tested the Makefile against my new refdbxml and refdbxmlrc 
files using all the xslt and fo processors included to date.

This includes: xalan, xt, saxon, saxon-xerces, xsltproc, passivetex, 
fop, xep and jfor.

In every case (except jfor), the Makefile produced the desired output 
without error.

In another post I've mentioned the problem with jfor, which has to do 
with DocBook rather than refdb.

The only thing still bugging me is the theoretical possibility of 
invoking refdbxml with a mismatch between the fo processor and output 
type (eg. jfor processor with pdf output).  Something like the following 
code could be inserted at the start of process_print:

........................................................................
rtf_generators="jfor"
pdf_generators="fop xep passivetex"

case $outformat in
    rtf ) generators=$rtf_generators;;
    pdf ) generators=$pdf_generators;;
esac

processor_outformat_match=false
for generator in $generators ; do
    [ "$generator" = "$fo_processor" ] && processor_outformat_match=true
done

if [ ${processor_outformat_match} = false ] ; then
    echo "Specified FO processor: $fo_processor."
    echo "Specified output format: $outformat."
    echo "Error: $fo_processor does not produce $outformat output."
    exit 1
fi
........................................................................

The first two lines -- variable declarations -- could be placed near the 
top of refdbxml for ease of maintainability.  The remaining lines need 
no further editing even if the list of rtf and pdf FO processors changes.

Here is the output if I specify FO processor = jfor and output format = 
pdf :

........................................
Specified FO processor: jfor.
Specified output format: pdf.
Error: jfor does not produce pdf output.
........................................


Other than that, I think it might do for now :-) .

Regards,
David

[Refdb-users] rtf output from makefile fails

[David N. <dav...@bi...>]

Hi all,

I've been exploring the DocBook XML --> RTF output from refdb's make 
(refdbxml) system.

Currently, attempting to output even the simplest XML document as RTF 
will fail with a jfor error message similar to:

....................................................................................................................................
org.xml.sax.SAXException: IOException in IBuilder: 
org.jfor.jfor.converter.ValueConversionException: conversion factor not 
found for 'in - -4pc' units
....................................................................................................................................

Anyone playing with XML -> FO -> print formats may have encountered our 
old friend: 'in - -4pc'.

For example, the default XML -> PDF pathway via xsltproc and passivetex 
gives output with '- -4pc - -4pc' in the top left of every page.

A little googling turns up the following newsgroup posting from (XSL 
guru) Bob Stayton 
<http://sources.redhat.com/ml/docbook-apps/2003-q3/msg00631.html> where 
he explains the cause of the problem.

In short, when converting DocBook to FO, XSLT processors commonly put in 
a margin instruction like this:

    margin-left="1in - -4pc"

The '-4pc' is a negative expression.  According to Stayton it is legal, 
but it is obviously not handled very well by some FO processors, 
including passivetex.

The only two FO -> RTF processors I've tried -- jfor and XMLmind's 
fo2rtf -- both choke on these margin expressions.

Until a sufficiently robust FO --> RTF processor comes along, I fear 
that RTF output from DocBook XML will not be possible.

Regards,
David.

P.S.  I see that the jfor project is being folded into Apache's FOP.  
The plan is to lose jfor's frontend converter (which is causing the 
problems) in favour of FOP's frontend parsing and interpretation 
engines.  The remains of jfor will form an additional FOP backend for 
RTF generation.  Maybe when that happens we can plug it into refdb for 
RTF output.

[Refdb-users] Setting up 'jfor' for rtf output

[David N. <dav...@bi...>]

Hi all,

When using refdb makefile to convert DocBook XML --> RTF, the refdb 
scripts (actually refdbxml) rely on 'jfor'.

jfor converts FO to RTF and is available from 
http://sourceforge.net/projects/jfor.

The documentation can optimistically be called 'minimal'.

I included the jfor.jar and xerces.jar files in my classpath, but got 
the following error:

Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/log/Hierarchy
        at org.jfor.jfor.main.CmdLineConverter.<clinit>(Unknown Source)
        at ch.codeconsult.jfor.main.CmdLineConverter.main(Unknown Source)

It seems recent versions of jfor now rely on Apache's logkit.jar.  It 
may already be on your system if you've installed apache.  For Debian 
users, it's included in the 'liblogkit-java' package.  I'm not sure 
about RPM-based systems.  If you can't grab a package, the project 
homepage (http://avalon.apache.org/logkit/) has a link to a download page.

So, jfor relies on jfor, xerces and logkit.

My classpath looks like: 
/usr/share/java/jfor.jar:/usr/share/java/xerces.jar:/usr/share/java/logkit.jar

Regards,
David.

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Markus Hoenicka wrote:

>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable. I've
>tested the updated script with xsltproc and FOP. I'm currently
>updating my xerces and Saxon installations, but I expect this will
>work too.
>  
>
I'm afraid that further testing has shown up some problems with my 
refdbxml script.  While I thoroughly tested the pdf output, I didn't 
test rtf output.  I'm doing so now and have discovered some errors:

1. The test for valid fo_processor does not include 'jfor'.  Here are 
the problem lines:

.........................................................................................................
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ]; then
  echo "specify one of 'passivetex', 'fop', 'xep' with the -f option"
.........................................................................................................

and here's how it should read:

.........................................................................................................................................
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ] && [ ! $fo_processor = "jfor" ]; then
                                                                                                   
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  echo "specify one of 'passivetex', 'fop', 'xep', 'jfor' with the -f 
option"
                                                 ^^^^^^^^
.........................................................................................................................................


2. The test for whether classpaths were extracted from init file is 
defective.  The problem lines are here:

.............................................................
# Set classpath variables to default if not already specified
if ! [ -n "$xslt_processor" ]; then
                 ^^^^^^^^^
    xslt_processor=$classpath
         ^^^^^^^^^
fi
if ! [ -n "$fo_processor" ]; then
               ^^^^^^^^^
    fo_processor=$classpath
       ^^^^^^^^^
fi
.............................................................

and the corrected lines here:

.............................................................
# Set classpath variables to default if not already specified
if ! [ -n "$xslt_classpath" ]; then
                 ^^^^^^^^^
    xslt_classpath=$classpath
         ^^^^^^^^^
fi
if ! [ -n "$fo_classpath" ]; then
               ^^^^^^^^^
    fo_classpath=$classpath
       ^^^^^^^^^
fi
.............................................................


3. The jfor command still used the (old) default classpath instead of 
the fo classpath.  The offending lines:

...............................................................................
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$classpath" ch.codeconsult.jfor.main.CmdLineConverter 
$1 $2;;
...............................................................................

and the corrected version:

..................................................................................
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$fo_classpath" 
ch.codeconsult.jfor.main.CmdLineConverter $1 $2;;
                   ^^^
..................................................................................


You may have picked up some (or all) of these when you diplomatically 
refer to "obvious typos".

Apologies for the inadequate testing.

By the way, the current jfor is little difficult to get running, mainly 
owing to inadequate (actually, mostly absent) documentation.  I found 
the clue I needed in a jfor user-group posting (archived on GMane) about 
the Windows version!  It's obviously nothing to do with refdb directly, 
except that the Makefile relies on jfor for rtf output.  I'll post 
details direct to refdb-users with an informative heading for anyone 
else who's trying to set jfor up.

Regards,
David.

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Hi Markus,

>Thanks for that. I've added refdbxmlrc with some cosmetic changes to
>CVS. I've also integrated your refdbxml changes into the official
>version which also required some Makefile.am and configure.in
>hacking. I've fixed a few obvious typos in the file you sent and made
>some minor changes, like parametrizing the xep root variable.
>

I missed something very obvious that would remove the need to 
parameterise xep's root variable: the install process creates a shell 
script: 'xep.sh'.  It contains a customised launch command including 
classpath and ROOT parameters appropriate for that computer.  Here, for 
example, is the shell script as built on my system during the xep 
install process:

..........................................................................................................................
#!/bin/sh

# This script encapsulates a standard XEP call.

JAVA_HOME=/usr/local/java/j2sdk1.4.2_03/jre

XEP_HOME=/home/david/progs/apps/xep

CP=$JAVA_HOME/lib/tools.jar:$XEP_HOME/lib/xep374_trial.jar:$XEP_HOME/lib/saxon.jar:$XEP_HOME/lib/xt.jar

$JAVA_HOME/bin/java -classpath $CP com.renderx.xep.XSLDriver 
-DROOT=$XEP_HOME $*
..........................................................................................................................

Providing xep.sh is on the system path, xep can be invoked in 
process_print thus:

    xep.sh -fo $1 -pdf $2

This would remove the need to specify xep's root directory.

The only potential problem is that the installer does not place xep.sh 
in a standard system directory, like /usr/local/bin or /usr/bin.  IMO, 
however, that can rightfully be considered part of the xep install 
process rather than part of the refdb configure process.  If you changed 
the xep launch command to use xep.sh, perhaps a note in the init file 
could indicate the need to make sure xep.sh is on the system path?

Regards,
David.

Re: [Refdb-users] User feedback 3

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > After installing that file, saxon happily processed the document to 
 > completion and the make process proceeded to conclusion.  I've tested 
 > both html and pdf output pathways and both work.  Thanks for the fix.
 > 

Great. I'll check in the new version of the Perl script then.

 > P.S. Does this mean I'm the first person to try refdb/xml/saxon (at 
 > least beyond giving up when saxon failed)?
 > 

Apparently?! I've got no idea what people out there use for their XML
processing.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] User feedback 3

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > At the end of this message please find:
 > 1. An init file for refdbxml: refdbxmlrc
 > 2. A re-written refdbxml to use the init file
 > 

Thanks for that. I've added refdbxmlrc with some cosmetic changes to
CVS. I've also integrated your refdbxml changes into the official
version which also required some Makefile.am and configure.in
hacking. I've fixed a few obvious typos in the file you sent and made
some minor changes, like parametrizing the xep root variable. I've
tested the updated script with xsltproc and FOP. I'm currently
updating my xerces and Saxon installations, but I expect this will
work too.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Hi Markus,

>David Nebauer writes:
> > At this point may I make a bold suggestion: the addition to refdb of a 
> > refdbxml configuration/init file, presumably .refdbxmlrc.  This would 
> > have the following advantages:
>  
>
<snip>

>I strongly encourage you to whip up a proof of concept. The shell
>magic to read config files is not that hard BTW, the db2ris script
>shows an example how to do this.
>

At the end of this message please find:
1. An init file for refdbxml: refdbxmlrc
2. A re-written refdbxml to use the init file

I had these goals in mind when re-writing refdbxml:
1. Ability to specify in init file which XSLT processor to use.
2. Add to saxon support for xerces xml parser and the apache resolver.
3. Ability to use additional FO processors (fop and xep) and specify in 
init file which one to use.
4. Ability to declare classpaths for java-based processors in init file 
-- with a different classpath for XSLT and FO processors.

First, some notes about the new files:

- I've added an extra command line parameter to refdbxml: -f   -- the fo 
processor
- kept boilerplate code from db2ris about looking for global config file 
(eg. /etc/refdb/refdbxmlrc)
    - if you decide to keep this, you'll need to adjust the 
configuration install step to insert $globalconfig as per db2ris
- I've added 'saxon-xerces' as an XSLT processor option: it uses the 
xerces xml parser instead of the inbuilt Aelfred parser (everybody does 
this, and all the experts recommend it)
- I've added to both saxon and saxon-xerces command lines the options 
for catalog resolution
- until now passivetex has been the only fo processor -> I've added fop 
and xep.  There's a new function called 'process_print' which handles 
the conversion from fo to printable output (rtf|pdf)
    - there's a possibility someone could invoke refdbxml with a pdf fo 
processor (like passivetex or fop) but specify rtf output.  I'm not sure 
what would happen then, but I don't think it would be pretty
    - there's a nasty hack regarding xep -- see notes in refdbxml 
regarding it
-  not sure what happens if someone puts a space in their classpath
- original default classpath from refdbxml is still there and is used if 
none specified in init file.

Results of testing (via 'make'):

- tested with no init file --> WORKED
- tested with init file present but all options commented out --> WORKED
- tested with XSLT processor xsltproc --> WORKED
- tested with XSLT processor saxon --> WORKED
- tested with XSLT processor saxon-xerces --> WORKED
- tested with FO processor passivetex --> WORKED
- tested with FO processor fop --> WORKED
- tested with FO processor xep --> WORKED (albeit with nasty hack)

I haven't tested it with jfor, xt or xalan, but the commands are 
identical to those present in the original refdbxml, so they should work.

All comments, especially (constructive) criticism welcomed.

Regards,
David.


refdbxmlrc:
...........................................................................................................
# This is an example configuration file for refdbxml, the XML transformation
# tool of RefDB
# RefDB is a reference database and bibliography tool, see
# http://refdb.sourceforge.net for further information

# Syntax rules of this file:
# 1. Each line contains a pair of variable name and variable value,
#    separated by whitespace.
# 2. The hash (#) denotes the start of a comment, the rest of the line
#    will be ignored
# 3. The line ending must be Unix-style (LF) regardless of the operating
#    system


# Note: Each of these options can be overridden at execution time by
# invoking refdbxml with command line options.
# To see the available options, type 'refdbxml -h' or refer to the manual.


## XSLT processor.
# An xslt processor is used to transform your DocBook xml document to
# (x)html or fo.
# Currently available choices are:
#   xalan
#   xt
#   xsltproc (default)
#   saxon
#   saxon-xerces
# Note: 'saxon-xerces' refers to the saxon xslt processor using the
# xerces xml parser from Apache.
# Note: 'saxon', both with and without 'xerces', will use the Apache 
resolver.
# Note: _You_ must ensure that the xslt processor is installed and
# correctly configured.  RefDB does not check.
#xslt_processor    xsltproc

## XSLT classpath
# You only need to set this variable if your XSLT processor is java-based.
# If it's not java-based (eg. xsltproc), don't set this variable.
# Some XSLT processors _are_ java-based (including xalan, xt and saxon)
# and need to access certain directories and java class files.
# This is done by specifying a classpath.
# Refer to the application's documentation for further information
# about the necessary classpath.
# One approach is to choose a directory and put in it symlinks to
# the required jars, so the classpath may be something like:
#   /usr/share/java
# Do not use backslashes to concatenate lines.
#xslt_classpath    /usr/share/java

## FO processor
# When producing printed output the xslt processor produces a "formatted
# objects" file (.fo).  An FO processor then transforms this to printed
# output.
# Currently available choices are:
#   passivetex (default) -> pdf output
#   fop                  -> pdf output
#   xep                  -> pdf output
#   jfor                 -> rtf output
# Note: _You_ must ensure that the xslt processor is installed and
# correctly configured.  RefDB does not check.
#fo_processor    passivetex

## FO classpath
# You only need to set this variable if your FO processor is java-based.
# If it's not java-based (eg. passivetex), don't set this variable.
# Some FO processors _are_ java-based (including fop, xep and jfor)
# and need to access certain directories and java class files.
# This is done by specifying a classpath.
# Refer to the application's documentation for further information
# about the necessary classpath.
# One approach is to choose a directory and put in it symlinks to
# the required jars, so the classpath may be something like:
#   /usr/share/java
# Do not use backslashes to concatenate lines.
#fo_classpath    /usr/share/java


## Include following variables to cover all command line options
## Not needed with refdbnd/make system

## stylesheet
# refdbxml currently sets no stylesheet default, relying on command line
# option.  I'll do the same.
#stylesheet       

## output format
# The format of the output file.
# Current options are:
#   html (default)
#   pdf
#   rtf
# refdbxml currently sets outformat to html as default. I'll do the same.
#outformat    html
...........................................................................................................


refdbxml:
...........................................................................................................
#!/bin/bash
# refdbxml - creates formatted output from XML documents
# Markus Hoenicka <ma...@xx...> 2001-10-10
# $Id: refdbxml.in,v 1.9 2003/12/21 22:58:22 mhoenicka Exp $
# OPTIONS: -s (stylesheet) -h (invoke help), -p (processor), -t (output 
format)

## added extra option: -f (fo processor)

# relies on these external programs: SUN JRE, tex, passivetex, xmltex, JFOR
# at least one of: xerces/xalan, xp/xt, xsltproc, saxon
# and at least one of: passivetex, fop, xep

# no longer a user-customizable section in this file
# -> use config file instead

## initialise variables
# location of the stock DocBook and TEI XSL stylesheets
htmldb="/home/david/data/conf/refdb/xsl/html/docbook.xsl"
xhtmldb="/home/david/data/conf/refdb/xsl/xhtml/docbook.xsl"
fodb="/home/david/data/conf/refdb/xsl/fo/docbook.xsl"
htmltei="/teixsl-html/teihtml.xsl"
xhtmltei="/teixsl-html/teihtml.xsl"
fotei="/teixsl-fo/tei.xsl"

# the default xslt processor: xalan, xt, saxon, saxon-xerces or xsltproc
xslt_processor="xsltproc"

# the default fo processor: passivetex, fop or xep
fo_processor="passivetex"

# the path to the Java class repository. This assumes that all necessary 
.jar
# files are in this directory. If this is not the case, adding a few 
symlinks
# might be the simplest solution
classpath_root="/usr/share/java"
xslt_classpath=""
fo_classpath=""

# some defaults
stylesheet=""
outformat="html"

# determine configuration files
if [ ! -r "$globalconfig" ] && [ -n "$REFDBLIB" ]; then
    globalconfig=$REFDBLIB/refdbxmlrc
fi
userconfig=$HOME/.refdbxmlrc

if [ -n "$globalconfig" ] && [ -r "$globalconfig" ]; then
    allconfigs=$globalconfig
fi

if [ -r "$userconfig" ]; then
    allconfigs=$allconfigs" "$userconfig
fi

# read the settings in the configure file(s)
for config in $allconfigs; do
    while read refdbvar refdbval; do
    if [ -n "$refdbvar" ]; then
        if [ $refdbvar = xslt_processor ]; then
        xslt_processor=$refdbval
        fi
        if [ $refdbvar = xslt_classpath ]; then
        xslt_classpath=$refdbval
        fi
        if [ $refdbvar = fo_processor ]; then
        fo_processor=$refdbval
        fi
        if [ $refdbvar = fo_classpath ]; then
        fo_classpath=$refdbval
        fi
        if [ $refdbvar = stylesheet ]; then
        stylesheet=$refdbval
        fi
        if [ $refdbvar = outformat ]; then
        outformat=$refdbval
        fi
    fi
    done < $config
done

# set processor launch commands for functions which follow
# more maintainable (and less ugly -- check out saxon-xerces!)
# note: saxon|saxon-xerces habe command-line options for catalog resolving
case $xslt_processor in
    xalan    ) xslt_launch="org.apache.xalan.xslt.Process";;
    xt       ) xslt_launch="com.jclark.xsl.sax.Driver";;
    saxon    ) xslt_launch="com.icl.saxon.StyleSheet -x 
org.apache.xml.resolver.tools.ResolvingXMLReader -y 
org.apache.xml.resolver.tools.ResolvingXMLReader -r 
org.apache.xml.resolver.tools.CatalogResolver -u";;
    saxon-xerces ) 
xslt_launch="-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl 
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl 
com.icl.saxon.StyleSheet -x 
org.apache.xml.resolver.tools.ResolvingXMLReader -y 
org.apache.xml.resolver.tools.ResolvingXMLReader -r 
org.apache.xml.resolver.tools.CatalogResolver -u";;
    xsltproc ) xslt_launch="xsltproc --catalogs --xinclude";;
esac
   

## function definitions
# creates fo output from xml. Arguments: input_filename out_filename
process_fo () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} $1 -xsl 
$jfosheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jfosheet > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jfosheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jfosheet;;
    xsltproc ) ${xslt_launch} $fosheet $1 > $2;;
    esac
}

# creates html output from xml. Arguments: input_filename out_filename
process_html () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} -in $1 -xsl 
$jhtmlsheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jhtmlsheet 
 > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jhtmlsheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jhtmlsheet;;
    xsltproc ) ${xslt_launch} $htmlsheet $1 > $2;;
    esac
}

# creates xhtml output from xml. Arguments: input_filename out_filename
process_xhtml () {
    case $xslt_processor in
    xalan    ) java -cp "$xslt_classpath" ${xslt_launch} -in $1 -xsl 
$jxhtmlsheet -out $2;;
    xt       ) java -cp "$xslt_classpath" ${xslt_launch} $1 $jxhtmlsheet 
 > $2;;
    saxon    ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jxhtmlsheet;;
    saxon-xerces ) java -cp "$xslt_classpath" ${xslt_launch} -o $2 $1 
$jxhtmlsheet;;
    xsltproc ) ${xslt_launch} $xhtmlsheet $1 > $2;;
    esac
}

# creates printable output (pdf|rtf) from fo.
# Arguments: input_filename out_filename
process_print () {
    case $fo_processor in
    jfor )
        java -cp "$classpath" ch.codeconsult.jfor.main.CmdLineConverter 
$1 $2;;
    passivetex )
        if [ ! -e $basename.aux ]; then
            touch $basename.aux
        fi
        cp $basename.aux $basename.aux.$$
        pdfxmltex $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        # the following loop should be fixed to run not more
        # than a fixed number of iterations.
        until diff --brief $basename.aux $basename.aux.$$; do
          cp $basename.aux $basename.aux.$$
          pdfxmltex $basename.fo
        done
        rm $basename.aux.$$;;
    fop )
        java -cp "$fo_classpath" org.apache.fop.apps.Fop -fo $1 -pdf $2;;
    xep )
        # Note the ugly hack (actually a cheat) in the xep command:
        # in my evaluation version xep needs to be run from the install
        # directory so it can check the license file. If run from any
        # other location it needs the -DROOT option set to that
        # install directory. Anybody know a way around this?
        java -cp "$fo_classpath" com.renderx.xep.XSLDriver 
-DROOT=/home/david/progs/apps/xep -fo $1 -pdf $2;;
    esac
}

# read the command line options
while getopts ":hp:f:s:t:" opt; do
  case $opt in
    h  ) echo "creates formatted output from a DocBook or TEI XML sources"
     echo 'usage: refdbxml [-h] [-p xslt_processor] [-f fo_processor ] 
[-s stylesheet] [-t outformat] file1 [file2...]'
     echo "Options: -h print this help and exit"
     echo "         -p specify xslt processor: xalan, xt, saxon, or 
xsltproc"
     echo "         -f specify fo processor: passivetex, fop or xep"
     echo "         -s stylesheet (the RefDB-generated driver file)"
     echo "         -t select the output format. Possible values are 
html, xhtml, rtf, pdf."
     exit 0 ;;
    p  ) xslt_processor=$OPTARG;;
    f  ) fo_processor=$OPTARG;;
    s  ) stylesheet=$OPTARG;;
    t  ) outformat=$OPTARG;;
    \? ) echo 'usage: refdbxml [-h] [-p xslt_processor] [-f 
fo_processor] [-s stylesheet] [-t outformat] file1 [file2...]'
     echo 'type refdbxml -h to invoke help'
     exit 1;;
  esac
done

# correct the index so the filename argument is always $1
shift $(($OPTIND - 1))

# test for valid arguments
if [ ! $outformat = html ] && [ ! $outformat = rtf ] && [ ! $outformat = 
pdf ] && [ ! $outformat = xhtml ]; then
  echo "specify one of 'html', 'xhtml', 'rtf', 'pdf' with the -t option"
  exit 1
fi

# pick stylesheet; the values "db" and "tei" use the stock stylesheets
# without any RefDB extensions. To format a document using RefDB 
bibliographies
# the RefDB-generated driver file must be specified here
case $stylesheet in
  db  ) htmlsheet=$htmldb
    xhtmlsheet=$xhtmldb
    fosheet=$fodb;;
  tei ) htmlsheet=$htmltei
    xhtmlsheet=$xhtmltei
    fosheet=$fotei;;
  *   ) if [ $outformat = "html" ]; then
        htmlsheet=$stylesheet
    elif [ $outformat = "xhtml" ]; then
        xhtmlsheet=$stylesheet
    else
        fosheet=$stylesheet
    fi;;
  \? ) echo 'type refdbxml -h to invoke help'
       exit 1;;
esac

# test for valid xslt processor
if [ ! $xslt_processor = "xalan" ] && [ ! $xslt_processor = "xt" ] && [ 
! $xslt_processor = "xsltproc" ] && [ ! $xslt_processor = "saxon" ] && [ 
! $xslt_processor = "saxon-xerces" ]; then
  echo "specify one of 'xalan', 'xt', 'saxon', 'saxon-xerces', 
'xsltproc' with the -p option"
  exit 1;
fi

# test for valid fo processor
# if none specified will be default (passivetex), which is legal
if [ ! $fo_processor = "passivetex" ] && [ ! $fo_processor = "fop" ] && 
[ ! $fo_processor = "xep" ]; then
  echo "specify one of 'passivetex', 'fop', 'xep' with the -f option"
  exit 1;
fi


# on Win32-cygwin, the native Win32 tools want the DOS path
# the variables $jfosheet and jhtmlsheet will receive the appropriate paths
if [ $OSTYPE = "cygwin" ]; then
    # get the full dos path of the classpath root
    osclasspath_root=$(cygpath -w $classpath_root)
    
classpath="$osclasspath_root\avalon-framework-4.0.jar;$osclasspath_root\batik.jar;$osclasspath_root\fop.jar;$osclasspath_root\jfor-0.5.1.jar;$osclasspath_root\jimi-1.0.jar;$osclasspath_root\logkit-1.0b4.jar;$osclasspath_root\sax.jar;$osclasspath_root\xalan.jar;$osclasspath_root\xerces.jar;$osclasspath_root\xp.jar;$osclasspath_root\xt.jar"
    jfosheet=$(cygpath -w $fosheet)
    jhtmlsheet=$(cygpath -w $htmlsheet)
    jxhtmlsheet=$(cygpath -w $xhtmlsheet)
else
    
classpath="$classpath_root/avalon-framework-4.0.jar:$classpath_root/batik.jar:$classpath_root/fop.jar:$classpath_root/jfor-0.5.1.jar:$classpath_root/jimi-1.0.jar:$classpath_root/logkit-1.0b4.jar:$classpath_root/sax.jar:$classpath_root/saxon.jar:$classpath_root/saxon-fop.jar:$classpath_root/saxon-jdom.jar:$classpath_root/xalan.jar:$classpath_root/xerces.jar:$classpath_root/xp.jar:$classpath_root/xt.jar"
    jfosheet=$fosheet
    jhtmlsheet=$htmlsheet
    jxhtmlsheet=$xhtmlsheet
fi

# Set classpath variables to default if not already specified
if ! [ -n "$xslt_processor" ]; then
    xslt_processor=$classpath
fi
if ! [ -n "$fo_processor" ]; then
    fo_processor=$classpath
fi

# loop over all files on the command line
for filename in $*; do
    if [ $OSTYPE = "cygwin" ]; then
      # get the full dos path of the file
      mypath=$(cygpath -w $filename)
    else
      mypath=$filename
    fi

    # extract the basename from the argument
    basename=${mypath%.*}

    case $outformat in
    rtf )
        process_fo $mypath $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        process_print $basename.fo $basename.rtf;;
    html)
        process_html $mypath $basename.html;;
    xhtml)
        process_xhtml $mypath $basename.xhtml;;
    pdf )
        process_fo $mypath $basename.fo
        if [ $? -ne 0 ]; then
          exit 1
        fi
        process_print $basename.fo $basename.pdf;;
    esac
done


exit 0
...........................................................................................................

Regards,
David.

Re: [Refdb-users] User feedback 3

[David N. <dav...@bi...>]

Hi Markus,

>I've updated the Perl script that generates the .xsl file and hope that the
>generated file works for Saxon as well. I've sent you an updated
>version by private mail. Please let me know whether or not it works.
>  
>

After installing that file, saxon happily processed the document to 
completion and the make process proceeded to conclusion.  I've tested 
both html and pdf output pathways and both work.  Thanks for the fix.

Regards,
David.

P.S. Does this mean I'm the first person to try refdb/xml/saxon (at 
least beyond giving up when saxon failed)?

Re: [Refdb-users] User feedback 1

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > I cannot explain it, but this problem has spontaneously fixed itself.
 > 

If all bugs went away like this, you'd see me hanging out on the beach
on the Bahamas. I can't explain it either, but let's see whether the
bug pops up under particular circumstances. This might give a clue how
to really fix it.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de