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: <itemizedlist> <listitem> <para>TEXT</para> </listitem> <listitem> <para>TEXT</para> </listitem> </itemizedlist> Version-Release number of selected component (if applicable): passivetex-1.25-5 How reproducible: Always 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: * TEXT * TEXT Notice that there is a newline between the bullets and paragraphs. Expected Results: The output should be: * TEXT * TEXT Additional info: See also the following mailing list threads: http://lists.oasis-open.org/archives/docbook-apps/200406/msg00136.html http://lists.oasis-open.org/archives/docbook-apps/200408/msg00124.html
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: passivetex-1.25-3.noarch.rpm tetex-2.0.2-21.ppc.rpm tetex-afm-2.0.2-21.ppc.rpm tetex-dvips-2.0.2-21.ppc.rpm tetex-fonts-2.0.2-21.ppc.rpm tetex-latex-2.0.2-21.ppc.rpm xmltex-20020625-3.noarch.rpm xmlto-0.0.18-4.ppc.rpm I still saw the same problems.
I downgraded to (from an old Fedora Core): docbook-dtds-1.0-25 docbook-style-dsssl-1.78-4 docbook-style-xsl-1.65.1-2 docbook-utils-0.6.14-4 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): > > docbook-dtds-1.0-25 > docbook-style-dsssl-1.78-4 > docbook-style-xsl-1.65.1-2 > docbook-utils-0.6.14-4 > > 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 docbook-xsl. 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 various guides.
(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. Thanks. https://www.redhat.com/archives/fedora-test-list/2006-January/msg01242.html
(In reply to comment #19) > Pleas try out the test package and let me know if it fixes the problem for you. > Thanks. > > https://www.redhat.com/archives/fedora-test-list/2006-January/msg01242.html 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.) Thanks.
Confirmed fixed.
This bug is back. I see the symptoms in the original comment. I am using: passivetex-1.25-5.1.1 docbook-style-dsssl-1.79-4.1 docbook-style-xsl-1.73.2-2.fc8 docbook-dtds-1.0-32.fc8
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 following: <itemizedlist> <listitem> <para>foo</para> </listitem> <listitem> <para>bar</para> </listitem> </itemizedlist> outputs: * foo * bar However, ordered lists do not come out quite right: <orderedlist> <listitem> <para>foo</para> </listitem> <listitem> <para>bar</para> </listitem> </orderedlist> outputs: 1. foo 2. bar 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.