Bug 955996 (wkhtmltopdf-qt)
| Summary: | Review Request: wkhtmltopdf-qt - Customized version of the QT toolkit for generating PDFs using Web-kit | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ruediger Landmann <rlandman> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | fche, jfearn, kevin, me, mtasaka, package-review, plarsen, rdieter, rlandman+disabled, rlandman, sgordon, ti.eugene |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-18 04:09:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 928937 | ||
|
Description
Ruediger Landmann
2013-04-24 07:17:53 UTC
Umm... qt maintainers, how do you think of this? How about "NO!"? :-) This thing really needs to use the system Qt! Why do you want to use a customized version? There is no rationale given at all. (In reply to Kevin Kofler from comment #2) > How about "NO!"? :-) > > This thing really needs to use the system Qt! Why do you want to use a > customized version? There is no rationale given at all. Sorry Kevin. :) The version of wkhtmltopdf in Fedora right now does use system QT. However, upstream also provides a heavily customised QT package that allows them to provide considerably more functionality. From wkhtmltopdf --help: ================ Reduced Functionality: This version of wkhtmltopdf has been compiled against a version of QT without the wkhtmltopdf patches. Therefore some features are missing, if you need these features please use the static version. Currently the list of features only supported with patch QT includes: * Printing more then one HTML document into a PDF file. * Running without an X11 server. * Adding a document outline to the PDF file. * Adding headers and footers to the PDF file. * Generating a table of contents. * Adding links in the generated PDF file. * Printing using the screen media-type. * Disabling the smart shrink feature of webkit. ================ And this omits another key function: proper pagination. Cumulatively, these features make wkhtmltopdf a full-featured PDF layout tool; without them, the PDF output is not really any more sophisticated than "printing" a long HTML page to PDF. Of particular interest to Fedora docs people is the "Running without an X11 server" feature, which allows us to generate PDF at build-time in Koji. I'm certainly open to better ways of getting this functionality into Fedora, though! Cheers Rudi Running X code without a true X server is what Xvfb is for. For the other stuff (and possibly even for the possibility to use QtGui without X11, but that one sounds like a bad hack), wkhtmltopdf really needs to work on getting those patches into upstream Qt. I don't think shipping a patched Qt in Fedora for one application is practical. The hacked version is also much older than current upstream Qt and probably missing several security fixes; you're applying one of them, but I'm pretty sure there have been more since 4.8.0. (We COULD try to apply the patches which don't break other Qt apps in our qt packaging, but the more non-upstream patches we apply, the more work it is to maintain the package, and I haven't looked at the patches to see what kind of breakage (also for binary compatibility!) they can cause.) The tool seems to be very limited without QT - from the doc:
Items marked * are only available using patched QT.
--image-dpi * <integer> When embedding images scale them down to
--image-quality * <integer> When jpeg compressing images use this
--no-pdf-compression * Do not use lossless compression on pdf
--use-xserver * Use the X server (some plugins and other
--dump-default-toc-xsl * Dump the default TOC xsl style sheet to
--dump-outline * <file> Dump the outline to a file
--outline * Put an outline into the pdf (default)
--no-outline * Do not put an outline into the pdf
--outline-depth * <level> Set the depth of the outline (default 4)
--default-header * Add a default header, with the name of the
--disable-external-links * Do not make links to remote web pages
--enable-external-links * Make links to remote web pages (default)
--disable-forms * Do not turn HTML form fields into pdf form
--enable-forms * Turn HTML form fields into pdf form fields
--disable-internal-links * Do not make local links
--enable-internal-links * Make local links (default)
--exclude-from-outline * Do not include the page in the table of
--include-in-outline * Include the page in the table of contents
--print-media-type * Use print media-type instead of screen
--no-print-media-type * Do not use print media-type instead of
--disable-smart-shrinking * Disable the intelligent shrinking strategy
--enable-smart-shrinking * Enable the intelligent shrinking strategy
--disable-toc-back-links * Do not link from section header to toc
--enable-toc-back-links * Link from section header to toc
--footer-center * <text> Centered footer text
--footer-font-name * <name> Set footer font name (default Arial)
--footer-font-size * <size> Set footer font size (default 12)
--footer-html * <url> Adds a html footer
--footer-left * <text> Left aligned footer text
--footer-line * Display line above the footer
--no-footer-line * Do not display line above the footer
--footer-right * <text> Right aligned footer text
--footer-spacing * <real> Spacing between footer and content in mm
--header-center * <text> Centered header text
--header-font-name * <name> Set header font name (default Arial)
--header-font-size * <size> Set header font size (default 12)
--header-html * <url> Adds a html header
--header-left * <text> Left aligned header text
--header-line * Display line below the header
--no-header-line * Do not display line below the header
--header-right * <text> Right aligned header text
--header-spacing * <real> Spacing between header and content in mm
--replace * <name> <value> Replace [name] with value in header and
--disable-dotted-lines * Do not use dottet lines in the toc
--toc-header-text * <text> The header text of the toc (default Table
--toc-level-indentation * <width> For each level of headings in the toc
--disable-toc-links * Do not link from toc to sections
--toc-text-size-shrink * <real> For each level of headings in the toc the
--xsl-style-sheet * <file> Use the supplied xsl style sheet for
None of these options work - most important (to me) is being able to follow links. You get either core dumps or error messages with most features of the tool, saying the QT version isn't available.
I'm not specifically "married" to wkhtmltopdf - if a similar tool exist I'm happy to shift. Only found python-xhtml2pdf - and it seems very limited, such as no support for following (local) links.
(In reply to Kevin Kofler from comment #5) > (We COULD try to apply the patches which don't break other Qt apps in our qt > packaging, but the more non-upstream patches we apply, the more work it is > to maintain the package, and I haven't looked at the patches to see what > kind of breakage (also for binary compatibility!) they can cause.) Upstream has moved to QT 4.8.5 [1] and had a new release [2]. It might now be easier to workout how much of a burden carrying this as a patch would be on the QT maintainers? If the burden is too much we might seek a bundling exception due to how extensive the modifications are [3]. I have uploaded some test packages of builds for the latest master branches [4], in case anyone wants to see how the new features play out. 1: https://github.com/wkhtmltopdf/qt 2: https://github.com/wkhtmltopdf/wkhtmltopdf/releases/tag/0.12.0 3: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Modified_beyond_a_certain_extent 4: http://jfearn.fedorapeople.org/wkhtmltopdf/0.12/F19/ There are more and more non-upstream changes to Qt. This package is just not maintainable. Shipping a fork of the entire Qt is just not acceptable, and applying all those patches to the system Qt is not going to be possible either. (In reply to Kevin Kofler from comment #8) > There are more and more non-upstream changes to Qt. This package is just not > maintainable. Shipping a fork of the entire Qt is just not acceptable, and > applying all those patches to the system Qt is not going to be possible > either. +1 the change set large and I think we are better off trying to get an exception. IMHO, a bundling exception for something as large as Qt is not realistic either. How do you plan to maintain that fork? I see only 3 possibilities (with the reservation that I am not the one to make the decision on bundling exceptions, the FPC is): a) Upstream wkhtmltopdf gets their Qt changes upstreamed into upstream Qt. b) Upstream finds a way to make wkhtmltopdf work without modifying the entire Qt (maybe by forking selected 1 or 2 classes – the fewer classes, the more likely it is to get a bundling exception in Fedora). c) The package cannot go into Fedora (or only with all the features that require a patched Qt disabled). (In reply to Kevin Kofler from comment #10) > IMHO, a bundling exception for something as large as Qt is not realistic > either. How do you plan to maintain that fork? Upstream does most of that work. For security related issues the bundling rules specifically state how to structure spec files to make tracking bundled libraries easier for security response. > I see only 3 possibilities (with the reservation that I am not the one to > make the decision on bundling exceptions, the FPC is): > a) Upstream wkhtmltopdf gets their Qt changes upstreamed into upstream Qt. > b) Upstream finds a way to make wkhtmltopdf work without modifying the > entire Qt (maybe by forking selected 1 or 2 classes – the fewer classes, the > more likely it is to get a bundling exception in Fedora). > c) The package cannot go into Fedora (or only with all the features that > require a patched Qt disabled). wkhtmltopdf without the QT patches is already in fedora. FWIW you can't use that package to build PDFs for the fedora documentation, it just doesn't have the functionality required to be part of a publishing pipeline without the patches to QT. I'll make sure you get CC'd when the FPC ticket gets opened. The upstream's qt patching situation is unfortunate, but with bundling now being grudgingly approved, it's possible to move this neat package forward. Ewww, please no! A fork of the whole Qt is entirely unmaintainable! I'd also like to point out that QtWebKit, on which this software relies, is no longer supported by upstream Qt, and that the replacement (QtWebEngine) is known to NOT be usable for this use case (printing the HTML to PDF), so this program is effectively a dead end. If QtWebKit is abandoned, then this application's copy of a modified QtWebKit is no longer a "fork". It is the upstream's decision how maintainable they deem it, not ours. Bundling rules have been relaxed too in the meantime. "All packages whose upstreams allow them to be built against system libraries must be built against system libraries. All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries..." Seems to me that would apply here. https://github.com/wkhtmltopdf/qtwebkit "patched qtwebkit based on qt 5.4.2" Having said that, Rudi, I think you should withdraw this request and we should make publican build vanilla wkhtmltopdf PDFs on Fedora. No point spending anymore time on this. (In reply to Jeff Fearn from comment #17) > https://github.com/wkhtmltopdf/qtwebkit "patched qtwebkit based on qt 5.4.2" > > Having said that, Rudi, I think you should withdraw this request and we > should make publican build vanilla wkhtmltopdf PDFs on Fedora. No point > spending anymore time on this. Agreed; I think we're done here. |