Bug 1290423 - Publican generates pdf report without images on Fedora 23
Summary: Publican generates pdf report without images on Fedora 23
Status: NEW
Alias: None
Product: Publican
Classification: Community
Component: publican
Version: future
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carlos Munoz
QA Contact: Ruediger Landmann
URL:
Whiteboard:
Keywords:
: 1373135 1426840 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-10 13:22 UTC by Tibor Zimanyi
Modified: 2018-09-21 23:06 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed:


Attachments (Terms of Use)
Contains test report that can be used to reproduce the problem + report generated on fedora 22 + stacktrace + packageinfo from my system (418.13 KB, application/zip)
2015-12-10 13:22 UTC, Tibor Zimanyi
no flags Details

Description Tibor Zimanyi 2015-12-10 13:22:01 UTC
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

Comment 1 Jeff Fearn 🐞 2015-12-10 23:31:31 UTC
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"/>

Comment 2 Raphaël Hertzog 2015-12-18 08:27:40 UTC
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?

Comment 3 Jeff Fearn 🐞 2015-12-21 06:01:07 UTC
(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

Comment 4 Raphaël Hertzog 2015-12-21 08:30:07 UTC
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.

Comment 5 Tibor Zimanyi 2016-03-31 08:55:24 UTC
Thanks Raphael, that worked.

Comment 6 Jeff Fearn 🐞 2017-01-09 12:26:29 UTC
*** Bug 1373135 has been marked as a duplicate of this bug. ***

Comment 7 Jeff Fearn 🐞 2017-02-26 23:38:01 UTC
*** Bug 1426840 has been marked as a duplicate of this bug. ***


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