PDF Rendering

AdminBoB

When reading the ticket https://support.collectiveaccess.org/d/301881-best-pdf-renderer @monica states:

The options are either dompdf or wkhtmltopdf for html to pdf rendering. It sounds like you only have dompdf installed.

Question 1: Is it recommended to have both dompdf and wkhtmltopdf running?

Per the manual here:
https://docs.collectiveaccess.org/providence/user/setup/install/RHEL

Part of the setup instructions state to install wkhtmltopdf, which we have done:

[root@vm3279 ~]# wkhtmltopdf --version
wkhtmltopdf 0.12.6.1 (with patched qt)

But when you go into Admin > Configuration Check the system is showing the plugin as Not Available.
Plugin / Info / Status
PhantomJS / Renders HTML as PDF using PhantomJS / Not available
domPDF / Renders HTML as PDF using domPDF / Available
wkhtmltopdf / Renders HTML as PDF using wkhtmltopdf / Not available

Question 2: Is there an additional step that needs to be done to enable wkhtmltopdf? Perhaps I missed this in the manual.

Answering both questions would be appreciated.

monica

You don't need both installed, but wkhtmltopdf is a better tool (faster, more powerful).

If you have installed this and it's not showing in the configuration check, then make sure the path to the executable is set correctly in the external_applications.conf. This should be right for all common OS's, but depending how you installed it, it might be in a different place.

AdminBoB

Thank you for your reply @monica.
Here is the path on our server:

[root@vm3279 ~]# ll /usr/local/bin/wkhtmltopdf
-rwxr-xr-x 1 root root 41714880 Jun 27  2022 /usr/local/bin/wkhtmltopdf

And in Providence and Pawtucket2 under /app/conf/external_applications.conf it is set to:

# Path to wkhtmltopdf (http://wkhtmltopdf.org)
wkhtmltopdf_app = /usr/local/bin/wkhtmltopdf

This is a match.

Can you think of anything else that could be causing the issue. Or next steps to troubleshoot this. I have also asked our host to investigate. We are running:

OS: Rocky Linux 8.10 (Green Obsidian)
PHP: 7.4.33
CA Application Version: 1.7.11
Schema Revision: 158
Release Rype: RELEASE

Also, is it better to leave both active? Does the application 'pick' the preferred one to use?
Any suggestions / information would be appreciated.

monica

AdminBoB Yes it will pick the one it prefers and there is no issue with having both installed. dompdf is usually installed by default.

You can try and run the configuration check via the command line. There might be some sort of permissions issue, but according to your output, it looks like it should be executable by everyone.

Do a restart of your services, clear cache and look again.

AdminBoB

monica We have run fix permissions:

[root@vm3279 bin]# /usr/local/php74/bin/php ./caUtils fix-permissions
CollectiveAccess 1.7.11 (158/RELEASE) Utilities
(c) 2013-2019 Whirl-i-Gig

Determined web server user to be "apache"
Determined web server group to be "root"
Fixing permissions for the temporary directory (app/tmp) for ownership by "apache"...
Fixing permissions for the media directory (media) for ownership by "apache"...
Fixing permissions for the HTMLPurifier definition cache directory (vendor/ezyang/htmlpurifier/library/HTMLPurifier/DefinitionCache/Serializer) for ownership by "apache"...

Then we ran the clear-caches and then do-configuration-check which you can see the output below.

The command exits with Checking system configuration... this may take a while. which seems like the command finished incomplete as there is no further output. If I go back into the GUI, wkhtmltopdf is still reporting not installed.

At this point, this looks more like a coding issue than environment to me. Perhaps it's just the version we are on. I do not know. I am hesitant to upgrade until I am sure everything is working correctly and until some other questions posted in the forms are answered.

If you have other suggestions, I would like to hear them.

Here is the do-configuration-check output:

[root@vm3279 bin]# /usr/local/php74/bin/php ./caUtils do-configuration-check
PHP Warning:  Cannot load module 'imagick' because conflicting module 'gmagick' is already loaded in Unknown on line 0
CollectiveAccess 1.7.11 (158/RELEASE) Utilities
(c) 2013-2019 Whirl-i-Gig

Checking media processing plugins...
        Found Audio
        Found GD
        Found Gmagick
        Found GraphicsMagick
        Found ImageMagick
        Found Imagick
        Found Mesh
        Found Office
        Found PDFWand
        Found QuicktimeVR
        Found Spin360
        Found Video
        Found XMLDoc
        Found BinaryFile


Checking application plugins...
        Found ULAN
        Found WorldCat
        Found duplicateMenu
        Found historyMenu
        Found relationshipGenerator


Checking for barcode dependencies...
        (GD is a graphics processing library required for all barcode generation.)
                GD is installed; barcode printing will be available.


Checking system configuration... this may take a while.

[root@vm3279 bin]#

monica

AdminBoB You are using a very old version and I have no idea how the newer versions of the libraries that you probably have installed would be interacting with a version of CA that is now 4 years old. I have never used version 1.7.* so I am not even sure how well wkhtmtopdf even worked on that version.

Is there any reason that dompdf isn't doing what you need?

No matter what, I would still recommend upgrading to at least 1.7.17

AdminBoB

@monica I am just trying to follow the instructions in the manual which says to install wkhtmtopdf.

At this point we will focus on upgrading. I have posted a new thread on the best way to approach that.

Thank you for your help.

seth

If you're trying to run wkhtmltopdf and the paths are correct, but it's still not seeing it odds are it's erroring when run. If the binary returns a non-zero return value when run it'll be ignored. Typically this is because required supporting packages/libraries are missing.

Try running wkhtmltopdf on the command line as you. What do you get? Then try running it as the web server user (probably www-data) via sudo. What does that return?

yelto

When configuring wkhtmltopdf, it would appear that the patched QT version is required, at least for 2.0, as it seems to be called with --header-html and --footer-html, for instance, which are not understood by your average installed-by-default wkhtmltopdf. Is this correct?

If so the config check might not test wkhtmltopdf closely enough to determine its validity. MIght it not give the ok to installs that will then go on to fail silently?

Incidentally there is a line in the systems requirement doc about "Version 0.12.1 is supported. Do not use version 0.12.2, which has bugs that prevent valid formatting of output". How current is that?

seth

The patched QT version is the only version out there that actually works, as far as I can tell. wkhtmltopdf appears to be, for all intents and purposes, abandoned at this point.

The comment to not use 0.12.2 remains true. We haven't tried 0.12.1 in a while but it should still work. Getting it to run on a current OS is another matter.

yelto

Yes, the html to pdf open source space is shrinking. The thing is the latest fedoras and ubuntu 22 for instance ship with the minimally functional version, so that's bound to be baffling for new folks.

So the practical advice as of 2025 would be to install and use the patched qt wkhtmltopdf 0.12.6 (the latest, cf. https://wkhtmltopdf.org/downloads.html), or retreat to domPDF, right?

yelto

Not sure how much this helps with the specific issues @AdminBoB raises, but out of curiosity and interest for tradeoffs involved, I've done some cursory tests with dompdf and had some issues pop up.

If use_pdf_renderer is set to dompdf in app.conf, the config checker will report wkhtmltopdf as "not available", even when it is, which I think is surprising to the point of being a bug (it should say something like "available but not enabled as dompdf is selected").
When I try the checkboxes for adding logo, page number etc to PDF reports [CA 2.0], I don't see the corresponding output when using dompdf. Are those features expected to work with dompdf (they work with full-fat wkhtmltopdf)?

AdminBoB

Thank you @yelto, the information does help. I will take all this under consideration. Thanks again to you and @seth for replying.