Created attachment 1104335 [details] Contains test report that can be used to reproduce the problem + report generated on fedora 22 + stacktrace + packageinfo from my system Description of problem: When I generate pdf report on Fedora 23, the report is without images. When I try to generate the same report on Fedora 22, the report contains images. I think it may be related to fop tool. In Fedora 23, there is fop in version 2.0 in updates repo, in Fedora 22, fop is in version 1.1. There may be some API changes in fop that need to be addressed. Version-Release number of selected component (if applicable): 4.3.2 How reproducible: - I attached a test report. There is a makefile for the report so you can run "make pdf" to create the report. - You can find my package info related to publican in the attached zip. Steps to Reproduce: 1. Install latest publican-redhat package from [1]. 2. Download test report from attachements. 3. cd into reproducer/testReport 4. execute "make pdf" Actual results: The report is generated without images. Expected results: The report contains images. Additional info: [1] https://brewweb.devel.redhat.com/packageinfo?packageID=4421
Hi Tibor, FOP support in Publican has been deprecated for a few years now and will be removed in Publican 5.0. That being said, I believe this is likely a FOP issue and not a Publican one, as the XSL we use for FOP just configures the upstream DocBook XSL. This is all our XSL does: <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/fo/docbook.xsl"/> <xsl:param name="use.extensions" select="1"/> <xsl:param name="tablecolumns.extension" select="0"/> <xsl:param name="fop.extensions" select="0"/> <xsl:param name="fop1.extensions" select="1"/> <xsl:param name="linenumbering.extension" select="0"/> <xsl:param name="callouts.extension" select="0"/> <xsl:param name="highlight.source" select="0"/>
Hello, I got a similar report on the Debian side (also with fop 2.0 in unstable): https://bugs.debian.org/807860 Maybe it's a question of how fop gets called? Is it in the book directory so that "images/..." is a valid relative path?
(In reply to Raphaël Hertzog from comment #2) > Hello, I got a similar report on the Debian side (also with fop 2.0 in > unstable): https://bugs.debian.org/807860 > > Maybe it's a question of how fop gets called? Is it in the book directory so > that "images/..." is a valid relative path? It pushd's in to "$tmp_dir/$lang/xml" to run fop, which is the directory containing all the profiled XML, including all common images and anything required for publishing. After trying to build the PDF with publican, and before running clean, you could cd in to that directory and try running fop directly, maybe in debug or verbose modes, to see if it can be more informative. $ fop -q -c $common_config/fop/fop.xconf -fo $docname.fo -pdf ../pdf/$pdf_name
I don't get more information in verbose mode but I have found the problem (or at least a work-around). fop.xconf has a setting "<base>.</base>" and it seems that fop 2.0 takes this as the directory where fop.xconf is stored... So while in "$tmp_dir/$lang/xml" I simply did this and it worked: $ cp /usr/share/publican/fop/fop.xconf ./ $ fop -c fop.xconf -fo $docname.fo -pdf ../pdf/$pdf_name Looks like an easy fix.
Thanks Raphael, that worked.
*** Bug 1373135 has been marked as a duplicate of this bug. ***
*** Bug 1426840 has been marked as a duplicate of this bug. ***