From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Description of problem:
When using xmlto to produce a PDF file from a XML/DocBook source, the following:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create an XML DocBook document containing an itemized list.
2. Process the document into PDF using xmlto pdf $<.
3. View the resulting PDF using evince.
Actual Results: Itemized lists are rendered like this:
Notice that there is a newline between the bullets and paragraphs.
Expected Results: The output should be:
See also the following mailing list threads:
I have the same problem. I've tried older versions of the stylesheets and it
doesn't make a difference, it appears to be a bug in passivetex (or perhaps in
the underlying tetex) that has been introduced since FC3, because I definitely
didn't have this problem with FC3.
Also the version of this bug should be changed to "fc4", because it is a bug in
the current fc4 version, not just rawhide (aka "devel").
I tried going back to passivetex-1.25-3 (version in FC3), but I still get the
same problem, so I suspect that switch to using tetex-3.0-4 in FC4 may have
introduced some issue with passivetex. I would test the latest passivetex
(1.25-3) on against tetex-3.0-4, but I would have to go back to an FC3 machine,
which I don't have around just now. It would be useful if somebody could see if
they could reproduce (or otherwise) this bug on an FC3 machine with the XSL
stylesheets and passivetex from FC4.
(In reply to comment #2)
> I would test the latest passivetex (1.25-3) on against tetex-3.0-4,
Correction: I would test the latest passivetex (1.25-5) against the FC3 version
of tetex (2.0.2).
I tried this with a FC5ish Raw Hide, but downgraded to the following (FC3) packages:
I still saw the same problems.
I downgraded to (from an old Fedora Core):
and used the xml-dtd-4.1.2 DTD (instead of xml-dtd-4.4.)
Everything worked fine.
In fact, I was able to return all of my other packages to Raw Hide.
See also http://sources.redhat.com/ml/docbook-apps/2003-q4/msg00866.html.
Created attachment 122680 [details]
Patch to docbook-style-xsl's FO lists.xsl to fix lists
I don't know if this should be fixed in passivetex or docbook-style-xsl. I was
able to modify docbook-style-xsl in order to fix this.
Thanks. Applied in 1.69.1-2.
(In reply to comment #5)
> I downgraded to (from an old Fedora Core):
> and used the xml-dtd-4.1.2 DTD (instead of xml-dtd-4.4.)
> Everything worked fine.
> In fact, I was able to return all of my other packages to Raw Hide.
> See also http://sources.redhat.com/ml/docbook-apps/2003-q4/msg00866.html.
I will check this on FC4 as well.
Please could have an update for Fedora Core 4...? ;-) Hint, hint.
PS. Since this is a bug in docbook-style-xsl, the component should be switched
to that from passivetex so that users with the same problem will find it correctly.
Well, really it's a bug in passivetex, and we are working around it in docbook-xsl.
Reopening for FC4 update.
(In reply to comment #9)
> Well, really it's a bug in passivetex, and we are working around it in
Ah, so the FO XML is correct, but passivetex can't handle the extra <fo:block>
commands, is that it? Got it.
I seem to recall some time ago that the upstream maintainers of the docbook
stylesheets, Bob Stayton and Norm Walsh weren't going to put much effort into
creating FO files that worked around/maintained compatibility with passivetex on
account of it not being very actively developed.
If that's the case what's the long term future of FO->PDF generation with a free
toolchain on Fedora? The only other free toolchain I know to get PDFs from FO
is Apache's FOP, but it isn't currently packaged in Fedora AFAIK. Also for a
long time FOP was in limbo.
I'm sort of hoping that xmlroff will take off. *shrug*
As I said, "I don't know if this should be fixed in passivetex or
docbook-style-xsl." The docbook-style-xsl package is just easier for me to
understand, so I fixed the problem there.
I think this should be a decent temporary fix..
Unfortunately, hope is not a plan (comment #12.) After patiently waiting months
for a new FO processor, I decided it was time to do something. The lack of a
passivetex maintainer is unfortunate, given that the system is nearly complete
and produces nice, LaTeX-typeset documents.
(In reply to comment #13)
> The lack of a passivetex maintainer is unfortunate, given that the system is
> nearly complete and produces nice, LaTeX-typeset documents.
Yep, and it's the only free FO processor that handles inline LaTeX math (in
<equation> elements) nicely, not suprising since it uses LaTeX as a backend! ;-)
I don't think FOP or xmlroff will do that. Perhaps Red Hat could find a
maintainer for passivetex, especially given that the Fedora Documentation
Project uses passivetex as the official backend for generating PDFs for the
(In reply to comment #10)
> Reopening for FC4 update.
ping for FC-4 update... ;-)
Created attachment 123418 [details]
Better patch: covers all cases
I just tested the patch, and I realised that the existing patch doesn't cover
all the possible problems with badly indented lists, because it only fixes it
for <orderedlist> and <itemizedlist>.
Here is an updated patch that fixes it for all other list types where the
indentation problem occurs (everywhere there is <fo:list-item-body>):
<varlistentry>, <step>s within <procedure>s and <callout>s
New patch incorporated into rawhide in 1.69.1-4. Thanks. (Still leaving open
for FC4 update.)
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.
Pleas try out the test package and let me know if it fixes the problem for you.
(In reply to comment #19)
> Pleas try out the test package and let me know if it fixes the problem for you.
I pulled the test package from updates-testing. It works for me.
(Note: there are still a lot of problems with the docbook stylesheets and PDF
production but that particular problem appears to be fixed.)
This bug is back. I see the symptoms in the original comment. I am using:
Patch fixing blocks in lists was dropped in FC-6 as not neccessary - because fix
was included in upstream tarball. Problem is that $passivetex.extensions xsl
variable has to be set to 1 to make it running. It could be done by changing one
line in /usr/share/sgml/docbook/xsl-stylesheets/fo/param.xsl - <xsl:param
name="passivetex.extensions" select="0"/> has to be changed to <xsl:param
name="passivetex.extensions" select="1"/> and then everything works as expected
for passivetex XSL FO processing. This should not be done by default as not
everyone is using passivetex, so WORKSFORME as it is.
I followed the instructions in comment #24. This fixes itemized lists. The
However, ordered lists do not come out quite right:
I would expect "foo" and "bar" to be on the same line as "1." and "2."
Ok, will check necessary changes in docbook-style-xsl to get it running ...
Ok, corrected for orderedlist/listitem, procedure/step , substeps/step ,
stepalternatives/step and callout. Built as docbook-style-xsl-1.73.2-9.fc9 ,
closing RAWHIDE. Please check if the behavior is correct now for you - on my
machine it worked without troubles - you have to activate passivetex.extensions
to get it running with passivetex.
Confirmed fixed in docbook-style-xsl-1.73.2-9.fc9.
Is there anything that can be done so this does not have to be manually
configured in /usr/share/sgml/docbook/xsl-stylesheets/fo/param.xsl? I'd like to
see this work out of the box.
(In reply to comment #28)
> Is there anything that can be done so this does not have to be manually
> configured in /usr/share/sgml/docbook/xsl-stylesheets/fo/param.xsl? I'd like to
> see this work out of the box.
Having passivetex.extensions = 1 (active) as default would break functionality
of fop(or something else) - so users of fop will start to complain afterwards.
In fact fop is not perfect implementation too and docbook-style-xsl package has
some workarounds for fop too, so they have to activate fop.extensions = 1 ...
and having this as default could break passivetex or something else. Previous
way done in older Fedora's was similar fix as this one but not dependent on
passivetex.extensions value - therefore it was causing troubles with other
formating objects processors. The only possible way to automate this is
therefore to fix that directly in passivetex - and to coordinate that fix with
texlive and maybe other packages that includes passivetex sources. Anyway - I
agree with you that it would be better to have outofthebox fixes and not
workarounds which requires user action.