I have a numbering scheme set up for a large document with a bunch of nested <section> tags. The idea is to show the number of the top level sections and then the page number within that.

So, with some markup that's nested like this:

<section>
   <section>content</section>
   <section>content</section>
   <section>content</section>
</section>
<section>
   <section>content</section>
   <section>content</section>
   <section>content</section>
</section>
<section>
   <section>content</section>
   <section>content</section>
   <section>content</section>
</section>

only the top level sections should be counted and the page count should reset for every new top level section. The output should look like this (depending on how long the nested sections are):

1-1
1-2
2-1
2-2
2-3
3-1
3-2
3-3

I actually have it working in the table of contents, which is using target-counter, but when I try to display the same counter in the page footer, the first number is always 0 and the second one works fine.

The CSS looks like this:

section {
  counter-increment: section; 
  counter-reset: page 1;
}

section section {
  counter-increment: none;
  counter-reset: none;
}

.toc a:after {
  content: leader('. ') target-counter(attr(href), section) "-" target-counter(attr(href), page);
}

.report-tag.current-page {
   content: counter(section); 
}

.report-tag.total-pages {
  content: counter(page);
}

The 'report-tag' elements are part of the markup that's inserted into the footer (using flow()). The class names aren't really relevant because I'm overriding some existing behavior (that also works fine).

Again, the numbering in the TOC is working how I want and both places are using the same counters so I'm not sure why the ones in the footer aren't working.

If only the first one isn't working, try using "counter(section, first)" as this will pick up the first value that is set on the page, not the value as it was at the start of the page, which might still be zero.

I changed it to counter(section, first) but it's still showing up as zero.

Could you attach a small sample document demonstrating the problem?

Here's an example report with html/css output and the generated PDF.


As you can see the numbering in the Table of Contents is correct but in the footer the first number is always 0.

1. QuireReport.zip‎ 4.6 MB

In 174cbc86-4499-4fe6-8129-75cd956c4cbf.css there are these rules:

.report-tag.current-page { content: counter(section) }
.report-tag.total-pages { content: counter(page) }

But in report_styles.css there are these conflicting rules:

.report-tag.current-page { content: counter(page) }
.report-tag.total-pages { content:counter(pages) }

I figured the ones in the (174cbc86-4499-4fe6-8129-75cd956c4cbf.css) stylesheet would override the other ones in report_styles.css. Or do the counters not work the same way as other css property values?

report_styles.css is a default that is applied to every report and then the other one is only applied to reports for a specific company.

Woops, yes you are right. The issue here is that the footer block is taking the counter values as they were when the footer block was reached, which is 0 for the section counter, and the page counter is special. We can test this by resetting the section counter to a different value, and seeing that it is repeated and still does not increment.

Would it be possible for you to use generated content directly in the @bottom page margin box instead, like this:

@page {
    @bottom { content: counter(section) "-" counter(page) }
}

Thanks for your help.

Does that have to do with where the footer markup is within the DOM? I'm not sure I understand how the counter values are being generated.

I can set the footer content in the CSS directly like you suggested, but it's kind of a workaround for how our system is currently set up. We have a UI for editing the header and footer blocks so that report editors can add their own content. There are placeholders that look like this:

[current-page] of [total-pages]

that are replaced with the HTML .report-tag elements, which have their content set in the default stylesheet. I'm basically just overriding that behavior here to create a different numbering scheme.

Report editors don't have access to the CSS so any time we have to add header/footer content there it means that the UI they're seeing is now inaccurate (header/footer blocks appear to be empty but there's still content showing up in the PDF).

I'm wondering if there's a way to get this kind of counter working by putting the footer markup somewhere else in the html so that it has access to the correct values.

If not we may have to consider changing our app so that the header/footer UI generates CSS rather than HTML.

I'm also having another issue with the page counter resetting.

In that same document, I added a counter to the Table of Contents/Appendices like this:

@page toc {
   @bottom {
     content: counter(page, lower-roman);
  }
}

.toc {
   counter-reset: page 1;
}

.toa {
   counter-reset: none;
}

So the TOC/TOA pages should be i, ii, iii, iv. But it's resetting to i when it gets to the TOA. I thought setting the counter-reset on that element to none would fix it but it doesn't seem to have any effect.

Is there some other reason the page counter would be reset?

That seems odd. Would you like to email me (mikeday@yeslogic.com) a short sample document? That might be the easiest way to track it down.

It's actually the same document I attached above. You just need to add those TOC styles into 174cbc86-4499-4fe6-8129-75cd956c4cbf.css

If I download and unpack QuireReport.zip, and add those rules to the stylesheet, then I get a single TOC page with "i" at the bottom, and a single TOA page with "ii" at the bottom.

OK so 5 months later I realize I never figured this out. If I upload a new sample document can you take a look for me?

Sure.