Currently, for my report generation process using HTML and CSS to manage page breaks dynamically. I've enabled the option for users to print multiple reports at once by combining them into different sections within a single HTML document. This helps prevent print spooling issues by reducing it to one job.
However, I am facing an issue regarding numbering the section pages within the larger dynamic HTML in the format "page x of n." When left to the printer, the entire document is numbered as one entity instead of each section separately.
I'm looking for a way to predict CSS page breaks to count them before printing and insert custom pagination elements, such as HTML tags, for each section within the extensive single document.
Despite searching for a solution, I haven't been able to find one yet. So, turning to Stackoverflow for assistance seems like the next best step.
UPDATE: Resolution Implemented:
I decided to follow Christopher's suggestion, which led me on the right path, although not executed verbatim. Using jQuery, I conducted calculations based on factors like paper size, margins, and font size to determine where page breaks should occur. By inserting designated elements with CSS properties for page breaking, I tracked the number of breaks and updated the "page x of n" information accordingly once all content was processed. This approach eliminated the need to pre-determine total pages at the start (thanks to jQuery .each method).
While this solution isn't flawless and has its limitations:
The inclusion of "page x of n" elements doesn't align them as traditional footers but places them at the bottom of every page's content. In my context, this compromise is acceptable.
Segmenting oversized content elements proved slightly challenging, especially since most content originated from PHP scripts. Despite some complexity, I managed to work around these issues, making assumptions that could be problematic with diverse printing conditions.
The accuracy of calculations hinges on presumptions about printed material dimensions, margins, font sizes, etc. Given my intranet setup, I can tolerate these compromises as they are controllable variables. Additional coding may accommodate minor variations in the future, such as changes in paper size.
Although it's not a perfect or robust solution, it resolves my immediate problem, enabling batch printing while managing spooling timeouts, maintaining pagination consistency, without resorting to generating intermediary PDFs for printing purposes.
Solving this challenge posed unexpected difficulty; thus, additional feedback and insights are still welcome.
Thanks!
UPDATE 2: Final Thoughts - Save Yourself the Hassle:
Despite diving deep into my unconventional strategy yielding some small successes, ultimately, the complications became unwieldy and prone to breakage upon any slight alterations in report structures, content updates, or paper sizes!
So, what did I learn from this experience? "Resistance is futile!" Just stick with PDFs. Feel free to begin the chorus of "we told you so" – I can handle it ;-)
Transitioning to the TCPDF library provided a solid resolution, albeit challenging to initially navigate. The library's examples were instrumental in empowering complete customization over my reports, now seamlessly generating them as intended. Consolidating multiple reports into a cohesive PDF resolved print spooling concerns, incorporating page groups for accurate numbering alignment.
If tackling similar endeavors, my advice would be to bypass the frustrations entailed with HTML/CSS reporting methods and opt for PDF solutions right away.