wkhtmltopdf generating wrong TOC links

[maggie44]

Expected Behavior

Links should point to the heading for that section as can be seen when done through the BookStack development environment.

Current Behavior

When exporting a page to pdf with wkhtmltopdf and opening it, clicking one of the TOC links, it doesn't take me to the correct location and shows a meaningless link address, like file:///tmp/knp_snappy5ff65ed5491ae7.13561238.html.

This behaviour cannot be reproduced on the official BookStack install or development environment, only the Linuxserver and Solidnerd images.

Steps to Reproduce

Steps to reproduce the behavior:

Create a page with some headers
Configure BookStack to use wkhtmltopdf for pdf-generating
Export and open
Click one of the TOC links

Process of elimination has narrowed this down to the version of wkhtmltopdf running:

Development environment: wkhtmltopdf 0.12.6 (with patched qt)
Linuxserver: wkhtmltopdf 0.12.5
Solidnerd: wkhtmltopdf 0.12.5

So I updated the Linuxserver image to the 0.12.6 (actually I bumped the Alpine container version to .13, which then pointed it to the new repository which had the 0.12.6 in it). But the issue still occurred.

Then I pulled the latest build directly from the website (https://wkhtmltopdf.org/downloads.html) into the Solidnerd container, and the issue was resolved.

The difference, is in 1. the wkhtmltopdf version became: wkhtmltopdf 0.12.6. In scenario 2. the version became: wkhtmltopdf 0.12.6 (with patched qt)

The solution then it appears, is to install wkhtmltopdf 0.12.6 (with patched qt. More can be read about qt here: https://wkhtmltopdf.org/downloads.html).

This should be relatively easy for the Solidnerd container as it can be pulled directly from the source.

For the Linuxserver though, which is Alpine Linux, there doesn't appear to be a version compatible with MUSL, so wasn't able to get the QT version installed.

Discussion over on BookStack that lead to here: BookStackApp/BookStack#2459 (comment)

A discussion on the wkhtmltopdf repo related to Alpine support: wkhtmltopdf/packaging#2

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[maggie44]

After reading up on different options, seems what we are left with is either:

1. use a custom wkhtmltopdf build for Alpine 3.12: https://github.com/Surnet/docker-wkhtmltopdf/blob/master/archive/alpine-wkhtmltopdf/Dockerfile_3.12-0.12.6-small. (note plans to move to 3.13 will prevent this at least temporarily: Rebasing to Alpine 3.13 #79).
2. Switch to a buster base image

Would be good to hear on which direction is preferred before submitting any pull requests.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[maggie44]

Still an issue. Pending a decision on the last comment.

[maggie44]

Revisiting this today, having read through all the different options, I think a Buster base option alongside the current Alpine one would likely be the most viable solution. Could pull with a :buster tag when requiring the features that are not compatible with Alpine, while still allowing those using the more basic features to have the option of a slimmer base image.

[aptalca]

Not an option. We do not have a Debian baseimage let alone an nginx baseimage on debian or ubuntu. Plus, we'd rather not support two separate images on different bases.

[maggie44]

Definitely not an option then. Back to the drawing board. Will persevere, but integrating all the Alpine build steps just to get the qt version, and then potentially have issues with alpine .13, and add more to have to support, just seems illogical. May just fork the repo to do it for those who need that specific feature. Will update here again in a few days.

[maggie44]

There doesn't appear to be any solution I would deem 'good'. As a workaround, users can follow some of the methods outlined on wkhtmltopdf/packaging#2. Once Alpine support is added (wkhtmltopdf/packaging#2) the issue will be resolved.

Another option is for Pandoc integration, discussion continues on the viability (BookStackApp/BookStack#2524).

Going to close this off as there doesn't appear to be anything that can be done/that is viable to do on the LinuxServer image side.