Bug 1290423
| Summary: | Publican generates pdf report without images on Fedora 23 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Publican | Reporter: | Tibor Zimanyi <tzimanyi> | ||||
| Component: | publican | Assignee: | Nobody <nobody> | ||||
| Status: | NEW --- | QA Contact: | Ruediger Landmann <rlandman> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | future | CC: | cbredesen, raphael, rlandman, Sascha.Manns, williamjmorenor | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | Type: | Bug | |||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Tibor Zimanyi
2015-12-10 13:22:01 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"/> 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. *** |