Red Hat Bugzilla – Bug 176766
Ugly header on PDF documents from DocBook
Last modified: 2009-06-23 11:06:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.12) Gecko/20051215 Epiphany/220.127.116.11
Description of problem:
The passivetex package does not understand the proportional-column-width keyword. This keyword is used by docbook-style-xsl-1.69.1-1.1's pagesetup.xsl to define the document header when transforming from DocBook to FO. See also http://firstname.lastname@example.org/msg07703.html.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a DocBook book document (foo.xml.)
2. Create an XSL wrapper (foo.xsl) that sets <xsl:param name="header.column.widths" select="'1 2 1'"></xsl:param>.
3. xmlto -x foo.xsl pdf foo.xml.
Actual Results: The xmlto program says:
! Emergency stop.
<to be read again>
! ==> Fatal error occurred, the output PDF file is not finished!
Transcript written on tmp.log.
make: *** [golem.pdf] Error 1
Created attachment 122679 [details]
Patch so that pagesetup uses percentages instead of proportional-column-width
The patch in comment #1 is against the FO pagesetup.xsl included in
docbook-style-xsl, not passivetex.
If header.column.widths is left at the default of "1 1 1" then the portion of
the header reserved for chapter names is too narrow. This results in a header
that looks like this:
Hardware and Operating System Installation
Thanks. Fixed in CVS.
From User-Agent: XML-RPC
docbook-style-xsl-1.68.1-1.1 has been pushed for FC4, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.
Because of 307001 it will be necessary to change the patch. I'll make the change
dependent on passivetex.extensions variable from param.xsl as the fix is
necessary only for passivetex and is breaking things for fop.
This is an issue again in docbook-style-xsl-1.74.0-5.fc10.noarch. Was the patch pulled back out? The solution proposed in Comment #1 once again fixes this for me.
Please read comment #7 ... it was not removed, but made dependent on passivetex.extensions parameter (in fact it's passivetex issue, but as passivetex is very difficult to fix and it's upstream is dead, it's easier to workaround it in docbook xsl stylesheets - unfortunately upstream of docbook stylesheets is very reluctant to add such workarounds for dead passivetex). So to make it work, you have to activate passivetex.extensions parameter in /usr/share/sgml/docbook/xsl-stylesheets/fo/param.xsl - and it will work correctly again. Activating it by default (or making that change/patch not dependent on passivetex-extensions parameter) will break fop functionality.
Could you please confirm that with correctly set passivetex.extensions parameter is the problem still fixed?
Note: this is not the only workaround for passivetex, there are in fact more such things - e.g. indexes, list-item-body, so activating this boolean for passivetex-only (no fop, no dblatex, no xmlroff) text processing is always good idea.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Closing WORKSFORME - as it works for me with passivetex.extensions enabled - and that's expected behaviour - to prevent breakage of fop functionality.