Desired capability pageNumber automatic counting in the footer adjusted by an offset value

[rietta]

This is a placeholder for an issue that I am having. Upon discovery of a solution, I plan to introduce a pull request to add this to the documentation so that future developers who want to do similarly will have a go-to solution with Grover.

I have been struggling for a day to render a PDF with page numbering that starts at an offset. The idea is that there will be a series of PDFs generated separately and then combined into a single file as a final step. My Ruby code will keep a running total of the pages already rendered and pass the start number into a the call to render a particular sub document.

This used to work with wicked_pdf with a page_offset parameter.

At the moment, footers with a span with the pageNumber class are rendering

<div style="font-size: 20pt !important!; font-weight: bold;">
    <p>
        Page <span class="pageNumber">[PAGE]</span>
    </p>
</div>

This results in:

• Page 1
• Page 2
• Page 3

but that number resets for each separate subdocument.

Though at the moment all attempts at styling it are being ignored. The resulting page number is a microdot no more than 1pt or less in size. Probably too small to even print. That I am setting to the side for now though.

I am attempting to inject some JavaScript into the print page layout with:

<% if @page_offset.present? %>
    <script language="JavaScript">
      window.addEventListener("DOMContentLoaded", (event) => {
          const pageNumberSpans = document.querySelectorAll(".pageNumber");
          pageNumberSpans.forEach((span) => {
              let pageNumber = parseInt(span.textContent);
              let adjustedPageNumber = pageNumber + <%= @page_offset.to_i %>;
              span.textContent = adjustedPageNumber;
          });
      });
    </script>
  <% end %>

But so far while no error is being output this is not working. The page numbers stay the same unchanged.

I will keep at this and will document here the found solution. I really think this is worthy of being added to the project's documentation as a need that will arise for others besides me.

[rietta]

Since this post, I have discovered that the style has to be specified in line with the footer content and that part seems to work.

<style>
    span.pageNumber {
        font-size: 100pt !important;
        color: red !important;
        font-weight: bold !important;
    }

    .pageFooter {
        font-size: 20pt !important!; 
        font-weight: bold;
        width: 100%;
        min-width: 600px;
    }
</style>
<div class="pageFooter">
    <p>
        Page <span class="pageNumber">[PAGE]</span>
    </p>
</div>

Very garish proof of life!

Next issue is still adjusting the page numbers to add an offset to each.

[rietta]

So far attempts to use CSS counters and JavaScript injection in the footer has not worked. IT seems that each page footer resets the counter independently.

Attempts at inline JavaScript is also not so far bearing fruit.

<div class="pageFooter">
    <span id="page_number"class="pageNumber">[PAGE]</span>
    +
    <span id="page_offset"><%= @page_offset.to_i %></span>
    =
    <span class="adjusted_page_number"></span>
    <p>
        JavaScript alternative
        <script language="JavaScript">
            window.addEventListener("DOMContentLoaded", (event) => {
                let p = parseInt(document.getElementById('page_number').textContent);
                let o = parseInt(document.getElementById('page_offset').textContent);
                let adjusted_page_number = p + o;
                results = document.getElementById('adjusted_page_number');
                results.textContent = adjusted_page_number;
                document.write("Hello, World!");
            });
        </script>
    </p>
</div>

Is rendering content such as:

4+3=
JavaScript alternative

But no math is being performed.

Investigating the CSS3 calc method did not yield results either.

[rietta]

For my own purposes, I may proceed with rendering these pages with a replacement text like [[PAGE]] and use sed or similar to replace page numbers with a counter in a Linux command line script as part of the PDF pipeline. I am already using pdfjam in this pipeline.

[rietta]

The "sed" approach is not proving to be promising even after using pdftk to uncompress the results. The footer content is not ASCII text. That would have been too good to be true.

[abrom]

The page numbers are injected by the browser after render and in a completely separate context. You can't interact with it in any way, except via the template configurations. In those you can style all you like.. and as the page content/styles/JS won't bleed into the header/footer.. the header/footer styles won't bleed into the page content.

If you're interested, this is the HTML used by Chromium to render the headers/footers, including the built in CSS classes etc available. This includes the .text class which will set the font size to something readable:

https://github.com/chromium/chromium/blob/bebb5f1deafb65e7232325161df09be8f04021a5/components/printing/resources/print_header_footer_template_page.html#L104

You can also see in the puppeteer documentation the classes that you can use on elements to signify the placeholders where you want the date/title/url/page number and total pages data to go:

https://pptr.dev/api/puppeteer.pdfoptions#headertemplate

If you're wanting to "offset" the page count so that it doesn't start at zero you'd need to essentially pad your document with a bunch of empty "pages".. render the PDF, then remove the pages after the render.

This shows an example of how to create the blank pages:

puppeteer/puppeteer#3383 (comment)

[rajeshsatpathy1]

I came across a similar issue (but on dotnet) and found a hacky way of doing it. I wanted to add {page_number} of {total pages}. Rather than trying to add the page number during the page generation page, we can try drawing it on an empty space in the footer template - after we have already merged the docs. At this stage, we have the total pages and can easily increment the current page number too. This is done using the PdfSharp library in dotnet. I'm hoping there is a similar library for your case.

I had almost gone with @abrom's idea, but the logic for having the right value for total_pages in the merging phase had me stuck. Was discussing with one of my colleagues and then the above idea struck.