The Wayback Machine - https://web.archive.org/web/20241010020745/https://github.com/BookStackApp/BookStack/pull/2311
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added custom page header and page count footers to export #2311

Closed
wants to merge 1 commit into from

Conversation

injektion
Copy link

#493

[submitting as a PR for visibility/feedback]

Hey @ssddanbrown - I've pushed a branch ( https://github.com/injektion/BookStack/tree/exportheaders ) which might help with this... For exports, it'll display a page number in the footer and allow users to create a page to include as a header on every page.

Most of the juice is in partials/export-header-footer.blade.php which is now included in all the /views/[books|chapters|pages]/export.blade.php and checks for a couple .env variables

EXPORT_HEADER_PAGE_SLUG=header
EXPORT_SHOW_PAGE_NUMBERS=true

There's some extra CSS added to partials/export-styles.blade.php which sets up a counter for pages, and if the .env is true will drop it into a footer div

        .pagenum:before {
            content: counter(page);
        }

As for the header, I'm currently letting the user define a page as their header, and then in partials/export-header-footer.blade.php using the slug of that page to import a header....

@if(env("EXPORT_HEADER_PAGE_SLUG"))
<div class="header">
    @php
        $PAGE = new \BookStack\Entities\Page();
        $page = $PAGE::where("slug", "=", env("EXPORT_HEADER_PAGE_SLUG"))->first();
        $page->html = (new \BookStack\Entities\Managers\PageContent($page))->render();
    @endphp
    {!! $page->html !!}
</div>
@endif

It's working fine to allow the user to create their own headers, add some page numbering, and export, but I think there's probably a better flow to how to get the user to define the page to use as their header (configuration page?)... Do you have any recommendations on where you'd like to see the header get defined, or do you think this will work for those who want it? Additional features or configurations you'd need to include this?

@ssddanbrown
Copy link
Member

ssddanbrown commented May 10, 2021

Hi @injektion, Sorry for my very late reply. I've just tried to test and finish this off to get it implemented but come across some challenges.

I done some changes in 370d07f to change how the header & footer is set, I changed things to use the theming system to set custom header/footer content instead of env options and existing pages. One of the challenges was getting the footer/header heights working with the page margin. Would be awkward but we could expose the options for these in some default header/footer content.

The main issue for this is WKHTMLtoPDF compatibility. WKHTMLtoPDF uses a completely different system for headers and footers. I did try to work around this (By extracting out headers/footers from the content and re-feeding in the support way) but It's even trouble to share the footer content from the DOMPDF solution since the margin control and page numbering are done in very different ways. I'm not really happy to implement a solution that just works for DomPDF, especially since we often guide people to use WKHTMLtoPDF in the event of issues. A random additional issue that I came across was that WKHTMLtoPDF completely fails to render any footer/header without using a patched QT version of the library.

Not sure where to go with this. Might look to see what WKHTMLtoPDF-only support would look like but it's still not ideal. Will have a think on it.

@injektion
Copy link
Author

@ssddanbrown Admittedly when I was piecing together the header/footer solution, I was working in a DOMPDF environment. Makes sense not to go that route if it doesn't work in the recommended WKHTMLtoPDF export.

You've got a better grasp on the project as a whole (and the changes since this was done back in last Oct), so if something comes together in your thoughts that you want to offload and throw your ideas this way, let me know and I can help take it off your plate.

@ssddanbrown
Copy link
Member

I think I'm just going to have to close this off. Thanks for what you've done here @injektion but with the current multiple PDF systems, and with there being a range of styling concerns with such headers/footers via DOMPDF, I can't really see us moving forward with this right now.

That said, the content of this PR, used with the visual theme system could provide a powerful combo for people to add such a feature to their own instance without altering core project files. If any amendments to the existing views or logic are desired, to make such theme system usage simpler, I'd be happy to accommodate. (Or even if more guidance on these systems was needed I'm happy to help).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment