-
Bug
-
Resolution: Timed out
-
Low
-
OnDemand
-
2
-
Severity 3 - Minor
-
When exporting a space via PDF, applying a custom style-sheet only allows you to create a table-of-contents style numbering for contents within a page.
When the same stylesheet is applied to the page titles and their hierarchy within a space, the sub-level entries are reset to zero:
PDF Export example:
Source Space example:
Custom style-sheet:
body {
counter-reset: h2counter 0;
}
h1 {
counter-reset: h2counter 0;
}
h2:before {
content: counter(h2counter) ".\0000a0\0000a0";
counter-increment: h2counter;
}
h2 {
counter-reset: h3counter 0;
}
h3:before {
content: counter(h2counter) "." counter(h3counter) ".\0000a0\0000a0";
counter-increment: h3counter;
}
h3 {
counter-reset: h4counter 0;
}
h4:before {
content: counter(h2counter) "." counter(h3counter) "." counter(h4counter) ".\0000a0\0000a0";
counter-increment: h4counter;
}
h4 {
counter-reset: h5counter 0;
}
h5:before {
content: counter(h2counter) "." counter(h3counter) "." counter(h4counter) "." counter(h5counter) ".\0000a0\0000a0";
counter-increment: h5counter;
}
The expectation is ToC styling should be available to style-sheet customisation within Confluence.
[CONFCLOUD-54336] Allow PDF Export TOC to be replicated via PDF Stylesheet
Looks like the bug is not yet fixed... after more than 5 years. I need it for my export very urgent! Please fix this bug. Thanks in advance.
I second Stephen comment: the issue is CSS scope (http://www.w3.org/TR/css3-content/#scope). I do get the numbering to work until 1 page deep (using .wiki-content / .pagetitle as reset) but anything deeper creates a new scope.
What will be useful is a div wrapper that wraps a page and all its children for all pages (like .page-tree). In this way we would have scopes that we can use (.page-tree .page-tree would define a child of a child scope).
Or yes, add the option to number the PDFs for us. Is not so "enterprise grade" without this.
Stephen Rees-Carter
added a comment - This "bug" is due to CSS counter scope issues, so is not technically a bug in Confluence itself. That said, numbering is a pretty important (dare I say essential) feature of a large PDF export, so it'd be great if Atlassian can find a solution and make it work.
Firstly, CSS scope counters are magical things which depend heavily on scope. This allows them to automatically nest and be used in properly formatted nested HTML layouts. Confluence, however, does not nicely format or nest the HTML and thus things break. When resetting a counter, this sets the scope for that counter to sibling elements, or child elements. This suits the Table of Contents because everything is on the same level within the container div. Each reset is within the right scope of the next elements, and everything just works.
Things get difficult when dealing with page headers. Each header tag (<h*>) for each page-header and the page-content headings are wrapped separately in .wiki-content and .pagetitle div's per page (i.e. one for the page-header, one for the page-content). This means that although you can increment and reset counters within each page-content block, any resets within this scope are not applied to the next page - and things reset to 0 or keep going up, depending. Sound confusing? It is...
Ultimately this means that you can reset individual counters globally (say on the <body> tag), or locally within each page... The former limits you to only numbering headings for individual pages, while the latter limits you to only numbering headings within pages.
Although I haven't tested it (yet), it should be possible to set up the numbering system using both global and local scope - but only for single level pages for the entire document. You'd then rely on global scope of the page headings, and reset the content headings within each .wiki-content block. In theory this would do the trick, but removes the benefits if nesting pages to reduce down long pages into shorter pages, for ease of editing.
Ultimately, a better solution (and a lot simpler for users) would be if there was an option when generating the PDF to enable heading numbers. Confluence then works out the numbers and rather than using CSS magic trickery, adds them as actual content during generation. Numbering would just work, and everyone would be happy. The current situation sucks and makes PDF generation look very unprofessional.
(I'm running a local Confluence 5.6.1 install)
Stephen Rees-Carter
added a comment - This "bug" is due to CSS counter scope issues, so is not technically a bug in Confluence itself. That said, numbering is a pretty important (dare I say essential) feature of a large PDF export, so it'd be great if Atlassian can find a solution and make it work.
Firstly, CSS scope counters are magical things which depend heavily on scope. This allows them to automatically nest and be used in properly formatted nested HTML layouts. Confluence, however, does not nicely format or nest the HTML and thus things break. When resetting a counter, this sets the scope for that counter to sibling elements, or child elements. This suits the Table of Contents because everything is on the same level within the container div. Each reset is within the right scope of the next elements, and everything just works.
Things get difficult when dealing with page headers. Each header tag ( <h*> ) for each page-header and the page-content headings are wrapped separately in .wiki-content and .pagetitle div's per page (i.e. one for the page-header, one for the page-content). This means that although you can increment and reset counters within each page-content block, any resets within this scope are not applied to the next page - and things reset to 0 or keep going up, depending. Sound confusing? It is...
Ultimately this means that you can reset individual counters globally (say on the <body> tag), or locally within each page... The former limits you to only numbering headings for individual pages, while the latter limits you to only numbering headings within pages.
Although I haven't tested it (yet), it should be possible to set up the numbering system using both global and local scope - but only for single level pages for the entire document. You'd then rely on global scope of the page headings, and reset the content headings within each .wiki-content block. In theory this would do the trick, but removes the benefits if nesting pages to reduce down long pages into shorter pages, for ease of editing.
Ultimately, a better solution (and a lot simpler for users) would be if there was an option when generating the PDF to enable heading numbers. Confluence then works out the numbers and rather than using CSS magic trickery, adds them as actual content during generation. Numbering would just work, and everyone would be happy. The current situation sucks and makes PDF generation look very unprofessional.
(I'm running a local Confluence 5.6.1 install) 
Jim Blinkhorn
added a comment - I must note, not only does the third level heading reset to zero, but the second level does not increment past x.1.
Jim Blinkhorn
added a comment - I must note, not only does the third level heading reset to zero, but the second level does not increment past x.1.
Hi everyone,
Thank you for previously raising this bug and bringing it to our attention.
Within our company roadmap and work capacity, we try to address or review each bug request but admit that not each one will be resolved. To continue the culture of being honest and open, we are closing this bug to focus on our upcoming roadmap for all Confluence users.
As we continue to roll out features we do look at requests made by our users and if you feel like this bug is still impacting your team please let us know.
Thank you again for providing valuable feedback to our team!