How can I count CSS page breaks for printed HTML?

Question

I am generating reports using HTML and I am using CSS to control the page breaking using page-break-after, etc. I have given the user the option to print multiple reports at once, which I create as sections of a single dynamically generated HTML document. Making it a single document allows it to be a single print job to avoid print spooling issues.

My problem is this: I would like to number the pages of a section of the larger dynamic HTML in the format "page x of n". However, if I let the printer do it, it sees the document (rightly) as a single document and numbers the whole document.

Is there any way I could determine when the CSS page breaks are going to occur, so I could count them for a section before printing, and put my own numbering (HTML element for example) in for the sections in the long single document?

It seems like there should be a way for me to do this, but over the past few days the solution eludes me, so I thought I would ping Stackoverflow.

UPDATE: What I ended up doing:

I have accepted Christopher's answer because although I didn't use it exactly, it pointed me in the right direction.

I ended up doing calculations on the content using jQuery, based on the paper size being printed to, margins, font size, etc. and then adding elements for page breaks that have CSS for page breaking. I track how many of the page break divs are added, and then update the html "page x of n" information in each page break div once all the content is processed. That allowed me to avoid having to know how many pages there would be at the beginning (thanks jQuery .each).

Obviously there are some issues with this solution:

1. The "page x of n" elements don't appear as true footers, but rather at the bottom of the content on each page. In my situation that is an acceptable compromise.

2. Splitting content elements that were in themselves larger than a page, especially considering most of the content is generated by php, got a little complicated. I made it work, but again, it requires assumptions that could break with printing variations.

3. The calculations depend on assumptions about the printed paper size, margins, font size, etc. In my situation running on an intranet, that is again an acceptable compromise because I can control those options. Additional code can be added to handle some amount of variation in future (paper size for example).

This solution, although not perfect and a little "brittle", solves my problem, allows me to print multiple reports at once avoiding printer spooling timeouts, keeps track of and restarts page numbering, and avoids generating PDFs as an intermediate step for printing.

I found this a oddly hard nut to crack, so I would still appreciate opinions and input on the solution.

Thanks!

UPDATE 2: Final solution... avoid the headaches yourself:

Although I went perhaps farther than I should have with this approach, with some small successes, in the end the solution really wasn't one because it just ended up being far too "brittle" to changes. Any change in report format, new content added to existing reports, paper size etc. broke the calculations and just ended up in a ridiculous amount of extra work!

So, the end solution? "Resistance is futile!" Just do the reports as PDFs. You may commence the "we told you so" chorus if you wish, I can take it ;-)

I went with the TCPDF library, which has been excellent, if a little tough going to get started. The examples are very helpful. Now I have complete customization over the report, and everything get generated as it should. Mulitple reports are easily created as a single PDF (preventing the print spooling issue) with page groups that allows for the numbering to work exactly as I need.

So, if you are trying to do something like this, I would recommend you cut to the chase, skip the frustration with HTML/CSS type reports, and do PDFs.