Here's some tricks pulled from a project I've not yet published for generating Resumes...
/* Thanks be to: https://stackoverflow.com/questions/19646835/print-repeating-page-headers-in-chrome/25880258#25880258
And may allow for repeated headers only in print preview
*/
div[class*="resume-section-experience-"] {
display: table;
width: 100%
}
div[class*="resume-section-experience-"] > div {
display: table-cell;
overflow: hidden;
}
/* Add further section repetition hiding here */
.resume-section-experience-professional ~ .resume-section-experience-professional > div:before {
content: "";
display: block;
margin-bottom: -3em; // inverse of header height
}
.resume-section-experience-volunteer ~ .resume-section-experience-volunteer > div:before {
content: "";
display: block;
margin-bottom: -3em; /* inverse of header height */
}
.resume-headings {
height: 3em;
}
div[class*="resume-section-experience-"] > div > div {
display: inline-block;
width: 100%;
vertical-align: top;
}
/**
* Attempt to keep section headings from displaying at the bottom of pages
* and discourage page brakes within various content blocks.
*/
@media print {
h2, h3, h4, ul, .professional-experience {
page-break-after: avoid;
}
pre, blockquote, ul, div[class*="-training"], div[class*="-requirements"], div[class*="-experience"], div[class*="-skills"], div[class*="resume-section-experience-"] {
page-break-inside: avoid;
}
}
... you'll have to adjust element names/classes that are targeted, and perhaps fiddle with spacing between paragraphs, but the above code is what functions similar requirements.
All that said, if you know that paragraphs are going to be broken between pages at some-point, it may instead be better to shrink the available height of that container such that there is space for fixed positioned headers and footers.
If ya edit your question to include some of the markup (and notify me), I'll try to swing through again with edits to this answer that may better address your specific use cases.
One additional note on the above CSS; for my use-cases I found that repeating header/footer data and then selectively hiding'em when not at the top/bottom of the page was easier to format between web and print views.
@dhiraj
... The main problem is how to generate page number
If page numbers be the main concern then it should be possible to utilize display: table
, display: table-footer-group
, and CSS's counter tricks...
print.css
/**
* print modifications **must** be within a style sheet
*/
@media print {
/*
* Note, forced page breaks are only for testing when content is insufficient
*/
.page_content__print_break {
page-break-after: always;
break-after: always;
}
footer.footer_content {
visibility: show;
opacity: 1;
filter: alpha(opacity=100);
position: fixed;
bottom: 0;
}
footer.footer_content::after {
counter-increment: page_number;
content: "Page:" counter(page_number);
}
}
index.html
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<meta charset="utf-8">
<title>Table based CSS footer example</title>
<style media="screen">
footer.footer_content,
.page_content__print_break {
visibility: hidden;
opacity: 0;
filter: alpha(opacity=0);
}
</style>
<link rel="stylesheet" href="print.css">
</head>
<body>
<section class="page_content">
<div class="page_content__row">
<p>This is where page content should be placed</p>
<p>
Thanks be to:
<a href="https://stackoverflow.com/questions/20050939">
Print page numbers on pages when printing html
</a>
</p>
</div>
<!--
Note, following element is only for this example and should
be removed for the use-case of this posted quesiton.
-->
<div class="page_content__print_break"></div>
<div class="page_content__row">
<p>
More example content to perhaps force a second page to be printed...
</p>
<p>
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
</p>
</div>
</section>
<footer class="footer_content" role="contentinfo"></footer>
</body>
</html>
Side note, upon reviewing the internally linked to Q&A above I found that @page
that you're using within the current question may not be feature fully supported by CSS, to get more fanciness requires PagedJS
And perhaps check the official CSS documentation on supported @page
features.
... however, after some testing it seems as though browser support has changed in recent years; both Firefox and Chrome seem to not do counter
stuff when printing, and page-break-*
has changed to break-*
though that property now seems to be ignored by both browsers :-|
Edit; the comment by @contm stated that linking style sheets vs. style within head
element may produce different results X-\
In fact after reviewing Mozilla's developer documentation on break-after
compatibility chart, this feature is supported by Internet Exporter
If I find anything that resolves these issues I'll be certain to pop by again with another edit to this answer.
Updates;
According to CSS spec. for @page
it's currently a WIP (draft or Work In Progress) so as of 2020 no vendors can be expected to implement.
Footers that are fixed
instead of repeated are only calculated once and after all increments have finished; an example that'll report Page: 2
on every page because there are two page_content__row
s...
print.css
@media print {
:root {
counter-reset: page_count;
}
.page_content__row {
counter-increment: page_count;
}
.page_content__print_break {
page-break-after: always;
break-after: always;
}
footer.footer_content {
visibility: show;
opacity: 1;
filter: alpha(opacity=100);
position: fixed;
bottom: 0;
}
footer.footer_content::after {
content: "Page: " counter(page_count);
}
}
... aside from third-party libraries the only other option that I can think of for customizing footer information is calculating page breaks at the time that your content is dynamically generated, and then injecting footer element(s) where needed. This of course has the huge draw-back in that client font/zoom settings will either mess-up footer customizations or have to be ignored, which if ya go that route it may be simpler to instead generate the PDF document server-side and provide a download link.