Bug 179518 - xmlto pdf crashes when DocBook tag colspec has a proportional width
xmlto pdf crashes when DocBook tag colspec has a proportional width
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xmlto (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Ondrej Vasik
Depends On:
  Show dependency treegraph
Reported: 2006-01-31 19:41 EST by Jeff Fearn
Modified: 2007-12-03 11:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-03 11:10:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Sample File (1.26 KB, text/xml)
2007-04-18 17:52 EDT, Jeff Fearn
no flags Details

  None (edit)
Description Jeff Fearn 2006-01-31 19:41:36 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.0.7-1.4.1 Firefox/1.0.7

Description of problem:
xmlto pdf will crash if a colspec has proportional colwidth

<colspec colnum="1" colname="col 1" colwidth="2.0in" />
<colspec colnum="2" colname="col 2" colwidth="2.0in" />

Crash and Burn:
<colspec colnum="1" colname="col 1" colwidth="1*" />
<colspec colnum="2" colname="col 2" colwidth="1*" />

Crash and Burn:
<colspec colnum="1" colname="col 1" colwidth="2.0in" />
<colspec colnum="2" colname="col 2" colwidth="2*" />

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Make a DocBook xml file with a table containg a colspec (http://www.docbook.org/tdg/en/html/colspec.html)
2. set the width attribute in the colspec to a proportional width i.e width="1*"
3. Run: xmlto pdf <file.xml>

Actual Results:  xmlto crashes and does not create the pdf file.

Expected Results:  Creation of a valid pdf file with correctly sized table entries.

Additional info:

! Missing number, treated as zero.
<to be read again>
l.584 />
        <fo:table-body><fo:table-row><fo:table-cell padding-left="2pt" paddi...

Error text:

! Emergency stop.
<to be read again>
l.584 />
        <fo:table-body><fo:table-row><fo:table-cell padding-left="2pt" paddi...

!  ==> Fatal error occurred, the output PDF file is not finished!
Transcript written on tmp.log.
Comment 1 Jeff Fearn 2006-09-20 18:19:03 EDT
I reccomend closing this won't fix. We are using fop to generate pdfs, all the
packages are from the Red Hat Application Stack, so we have a RHEL solution for
this now.

Below is a conversation I had with the xmltex author.

Cheers, Jeff.


I've looked at this again, and I just don't see a solution. To implement 
"proportional-column-width()" means
storing all the column dimensions, and then making a second pass over 
them to resolve the proportional
ones. Technically possible in TeX, but I don't have the brain to do it 
any more.  Most of the TeX stuff works
by a single sequential pass, and this sort of thing is a bit alien.

To be honest, if I had to deal with it, I'd write a pre-processing 
script in a rational
XML-processing language, and generate a new FO output file with all the 
widths resolved to absolute dimensions.  Do you think you can find
someone to do this?  Just a generic FO-simplifier. I could do it in XSLT,
but I don't that would be very efficient.

Sebastian Rahtz      

Information Manager, Oxford University Computing Services
13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

OSS Watch: JISC Open Source Advisory Service
Comment 2 Tim Waugh 2006-09-22 05:08:28 EDT
Should xmlto be using fop instead of xmltex then?
Comment 3 Jeff Fearn 2006-09-22 05:55:21 EDT
It would be good to have an option to be able to use fop instead of xmltex in xmlto.


xmlto pdf myfile.xml would use pdftex
xmlto -P fop pdf myfile would use fop

Presumably once -P is setup then adding support for other post processors would
be easy.

We are using a custom config file for fop, to setup fonts for translations,
would xmlto's -p option allow us to pass this config file path to fop?
Comment 4 Tim Waugh 2006-12-13 10:44:28 EST
Comment 5 Petr Mejzlik 2007-04-18 10:37:34 EDT
I'm not able to reproduce the bug on a RHEL 4 system. My configuration is:

Could you send me more info how to reproduce it? I think I'd need an example
.xml file and versions of relevant packages.

Thank you.

Comment 6 Jeff Fearn 2007-04-18 17:50:57 EDT
Hi Petr, I will attach a sample file that causes this error.

Here are the versions:


Cheers, Jeff
Comment 7 Jeff Fearn 2007-04-18 17:52:55 EDT
Created attachment 152961 [details]
Sample File
Comment 8 Petr Mejzlik 2007-04-25 09:58:07 EDT
Hi, I was able to find two workarounds:

1) Quick one: use "jw -f docbook -b pdf" instead of "xmlto pdf". This
uses the SGML toolchain instead of the XML toolchain.

2) "Correct" one: make xmlto pdf use fop instead of passivetex. I tested
the following procedure with with RHEL4 and BEA Java 1.4.2_11

  a) Install a recent version of fop. 
     You can find instructions at
*Or* you can install it from a RPM found at
(use rpm --nodeps if you have a different Java version).

  b) Install hyphenation patterns:
     (i) Download
     (ii) Copy fop-hyph.jar from the .zip file to the lib directory of
the fop installation. If you used the fop RPM mentioned above, copy
the .jar file to /usr/share/fop/lib.

  c) Change the backend for PDF generation from pdfxmltex to fop. Put
the following to /usr/share/xmlto/format/fo/pdf:

case "$1" in

  if [ "$VERBOSE" -ge 1 ]
    echo >&2 "Post-process XSL-FO to PDF"

  fop "$XSLT_PROCESSED" "$OUTPUT_DIR/$(basename ${XSLT_PROCESSED%.*}).pdf"


Now xmlto pdf should work as expected. 

Note: This is definitely not a complete solution of the bug. It would
require an update of the xmlto package, with a dependancy to a recent stable
fop package, and extensive testing.


Comment 9 Ondrej Vasik 2007-12-03 11:10:20 EST
Closing WONTFIX as suggested by reporter. Passivetex will probably not be
changed to support that, fop is doing good output in this case and option for
xmlto to use fop instead of xmltex/passivetex will be done in next release(s) of

Note You need to log in before you can comment on or make changes to this bug.