New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

counter-increment in '@page'? #289

Closed
xuhdev opened this Issue Jan 5, 2016 · 13 comments

Comments

7 participants
@xuhdev

xuhdev commented Jan 5, 2016

It seems that counter-increment does not work in @page currently (increase 1 for each page). It would be a nice feature to implement, can even work as a workaround for #93 at this point. Plus, it is useful to maintain multiple counters.

@xuhdev

This comment has been minimized.

Show comment
Hide comment
@xuhdev

xuhdev Jan 6, 2016

This complies with the specification here (section 7.1).

An example would be:

@page {
    counter-increment: test;
}

xuhdev commented Jan 6, 2016

This complies with the specification here (section 7.1).

An example would be:

@page {
    counter-increment: test;
}
@xuhdev

This comment has been minimized.

Show comment
Hide comment
@xuhdev

xuhdev Jan 6, 2016

Also, quoted from here, the page counter should also be able to reset and increment differently from the default.

A counter named ‘page’ is automatically created and incremented by 1 on every page of the document, unless the ‘counter-increment’ property in the page context explicitly specifies a different increment for the ‘page’ counter. The implied ‘page’ counter is a real counter, and can be directly affected using the ‘counter-increment’ and ‘counter-reset’ properties when named explicitly in those properties.

xuhdev commented Jan 6, 2016

Also, quoted from here, the page counter should also be able to reset and increment differently from the default.

A counter named ‘page’ is automatically created and incremented by 1 on every page of the document, unless the ‘counter-increment’ property in the page context explicitly specifies a different increment for the ‘page’ counter. The implied ‘page’ counter is a real counter, and can be directly affected using the ‘counter-increment’ and ‘counter-reset’ properties when named explicitly in those properties.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Jan 6, 2016

Member

Yes, this is a bug in WeasyPrint.

Member

SimonSapin commented Jan 6, 2016

Yes, this is a bug in WeasyPrint.

@liZe liZe added the bug label Jan 6, 2016

@zopyx

This comment has been minimized.

Show comment
Hide comment
@zopyx

zopyx Feb 29, 2016

It is also not possible to set the page counter to a dedicated number.

zopyx commented Feb 29, 2016

It is also not possible to set the page counter to a dedicated number.

@TravellerSam

This comment has been minimized.

Show comment
Hide comment
@TravellerSam

TravellerSam Apr 26, 2017

The last version of WeasyPrint I could successfully output pagination was 0.31. It worked pretty well:

   @page {
        size: A4;
        margin: 1cm;
        @bottom-center {
            counter-increment: page;
            content: "Page " counter(page) "/" counter(pages);
            margin-bottom: 1cm;
        }
    }

It did not respect the font-family or size value for the counter, however.

TravellerSam commented Apr 26, 2017

The last version of WeasyPrint I could successfully output pagination was 0.31. It worked pretty well:

   @page {
        size: A4;
        margin: 1cm;
        @bottom-center {
            counter-increment: page;
            content: "Page " counter(page) "/" counter(pages);
            margin-bottom: 1cm;
        }
    }

It did not respect the font-family or size value for the counter, however.

@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 5, 2018

Contributor

It's not too hard to implement. Did it already.
Got stuck with the question how to handle the page-based counter's scope.

Given the following CSS:

@page {
  counter-increment: pagebased;
  @top-center {
    counter-increment: pagebased 2;
  }
  @bottom-center {
    content: "pagebased counter on page " counter(page) " is: " counter(pagebased);
  }
}

What footers should be rendered?

Possible Outcome I

Supposed the pages are siblings, the margin boxes are children of their @page and @bottom comes after @top. Then applying the counter-inherit-rules from CSS Lists and Counters would produces this:

  • pagebased counter on page 1 is: 3
  • pagebased counter on page 2 is: 6
  • pagebased counter on page 3 is: 9
  • [...]

Not shure whether the margin boxes are sibling children of their page -- dont think margin boxes actually have a document order. According to CSS Paged Media they somehow should be handled as if they were the child of the deepest page-breaking element...

Possible Outcome II

Restricting the scope of the margin boxes' counter values to the margin box only (as the draft about Page-based counters seems to suggest) would produce that:

  • pagebased counter on page 1 is: 1
  • pagebased counter on page 2 is: 2
  • pagebased counter on page 3 is: 3
  • [...]

But when we do it like that I don't really see a use-case for a counter-increment in a margin box.


So
Not shure which algorithm is reasonable, not shure what the spec expects us to do.
At the moment I'm favouring the second one with restricted scope.

Contributor

Tontyna commented May 5, 2018

It's not too hard to implement. Did it already.
Got stuck with the question how to handle the page-based counter's scope.

Given the following CSS:

@page {
  counter-increment: pagebased;
  @top-center {
    counter-increment: pagebased 2;
  }
  @bottom-center {
    content: "pagebased counter on page " counter(page) " is: " counter(pagebased);
  }
}

What footers should be rendered?

Possible Outcome I

Supposed the pages are siblings, the margin boxes are children of their @page and @bottom comes after @top. Then applying the counter-inherit-rules from CSS Lists and Counters would produces this:

  • pagebased counter on page 1 is: 3
  • pagebased counter on page 2 is: 6
  • pagebased counter on page 3 is: 9
  • [...]

Not shure whether the margin boxes are sibling children of their page -- dont think margin boxes actually have a document order. According to CSS Paged Media they somehow should be handled as if they were the child of the deepest page-breaking element...

Possible Outcome II

Restricting the scope of the margin boxes' counter values to the margin box only (as the draft about Page-based counters seems to suggest) would produce that:

  • pagebased counter on page 1 is: 1
  • pagebased counter on page 2 is: 2
  • pagebased counter on page 3 is: 3
  • [...]

But when we do it like that I don't really see a use-case for a counter-increment in a margin box.


So
Not shure which algorithm is reasonable, not shure what the spec expects us to do.
At the moment I'm favouring the second one with restricted scope.

@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 5, 2018

Contributor

In 6.1. Page-based counters the draft states:

A counter-increment within either a page or margin context causes the counter to increment with the generation of each page box.

So -- no restricted scope for the margin boxes. Wondering what shall happen when the same counter is incremented in all 16 margin boxes of a @page. And all the margin boxes have a content outputting that counter(). 16 different values, ascending clock-wise? Same value for all?

Anybody knows how Prince handles that?

Contributor

Tontyna commented May 5, 2018

In 6.1. Page-based counters the draft states:

A counter-increment within either a page or margin context causes the counter to increment with the generation of each page box.

So -- no restricted scope for the margin boxes. Wondering what shall happen when the same counter is incremented in all 16 margin boxes of a @page. And all the margin boxes have a content outputting that counter(). 16 different values, ascending clock-wise? Same value for all?

Anybody knows how Prince handles that?

@danfitz36

This comment has been minimized.

Show comment
Hide comment
@danfitz36

danfitz36 May 16, 2018

it seems like counter(page) works just fine in weasyprint, but if I want to name any custom counter, it doesn't work. i'd really like to be able to give different sections of a document their own page numbers if possible.

danfitz36 commented May 16, 2018

it seems like counter(page) works just fine in weasyprint, but if I want to name any custom counter, it doesn't work. i'd really like to be able to give different sections of a document their own page numbers if possible.

@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 16, 2018

Contributor

As soon as somebody tells me how to decide on the counters in the 16 margin boxes -- see my comments above -- I'll create a pull request that will solve #93 too.

As I said: The hard part is not the implementation but understanding the draft (aka spec). I've been racking my brain and cant figure it out.

Contributor

Tontyna commented May 16, 2018

As soon as somebody tells me how to decide on the counters in the 16 margin boxes -- see my comments above -- I'll create a pull request that will solve #93 too.

As I said: The hard part is not the implementation but understanding the draft (aka spec). I've been racking my brain and cant figure it out.

@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 16, 2018

Contributor

According to @TravellerSam WeasyPrint 0.31 did it already -- will have a look how it was done then.

Contributor

Tontyna commented May 16, 2018

According to @TravellerSam WeasyPrint 0.31 did it already -- will have a look how it was done then.

@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 16, 2018

Contributor

Had a look at 0.31. Didnt help:
The page based counters page and pages are handled like in the current version: hard-coded, counter-increment in @page css is silently ignored.

Contributor

Tontyna commented May 16, 2018

Had a look at 0.31. Didnt help:
The page based counters page and pages are handled like in the current version: hard-coded, counter-increment in @page css is silently ignored.

@liZe

This comment has been minimized.

Show comment
Hide comment
@liZe

liZe May 17, 2018

Member

It's not too hard to implement. Did it already.

🎂

Anybody knows how Prince handles that?

pagebased counter on page 1 is: 0
pagebased counter on page 2 is: 0

A counter-increment within either a page or margin context causes the counter to increment with the generation of each page box.

The counters are incremented when the page box is generated, not when the page-margin boxes are generated. As the page box is generated before its page margins, it means that the counters are all incremented before generating the page-margin boxes.

But:

If a counter is reset or incremented within the page context, it is in scope for all page-margin boxes and obscures all counters of the same name within the document.
If a counter is reset or incremented within a margin context, it is in scope for that page-margin box and obscures any counters of the same name in both the page context and the document.

It means that @top-center { counter-increment: pagebased 2 } creates a different scope for this counter for this page box, leaving the original pagebased defined in the page context untouched.

It means that we get in @bottom-center:

  • pagebased counter on page 1 is: 1
  • pagebased counter on page 2 is: 2

If we had a counter(pagebased) in @top-center, it would give:

  • pagebased counter on page 1 is: 3
  • pagebased counter on page 2 is: 4

This rule is necessary to avoid evil manipulations of counters (and it makes our life easier):

  • you can't reset or increment document-context or page-context counters in page margins,
  • you can't reset or increment document-context counters in pages.
Member

liZe commented May 17, 2018

It's not too hard to implement. Did it already.

🎂

Anybody knows how Prince handles that?

pagebased counter on page 1 is: 0
pagebased counter on page 2 is: 0

A counter-increment within either a page or margin context causes the counter to increment with the generation of each page box.

The counters are incremented when the page box is generated, not when the page-margin boxes are generated. As the page box is generated before its page margins, it means that the counters are all incremented before generating the page-margin boxes.

But:

If a counter is reset or incremented within the page context, it is in scope for all page-margin boxes and obscures all counters of the same name within the document.
If a counter is reset or incremented within a margin context, it is in scope for that page-margin box and obscures any counters of the same name in both the page context and the document.

It means that @top-center { counter-increment: pagebased 2 } creates a different scope for this counter for this page box, leaving the original pagebased defined in the page context untouched.

It means that we get in @bottom-center:

  • pagebased counter on page 1 is: 1
  • pagebased counter on page 2 is: 2

If we had a counter(pagebased) in @top-center, it would give:

  • pagebased counter on page 1 is: 3
  • pagebased counter on page 2 is: 4

This rule is necessary to avoid evil manipulations of counters (and it makes our life easier):

  • you can't reset or increment document-context or page-context counters in page margins,
  • you can't reset or increment document-context counters in pages.
@Tontyna

This comment has been minimized.

Show comment
Hide comment
@Tontyna

Tontyna May 17, 2018

Contributor

Thats the interpretation I was hoping for -- especially when I contemplated accessing the page-context counters from document-context and vice versa.
What puzzled me the most was/is the consequence of this design: counter-manipulation in margin boxes is completely useless. At least I cant imagine a useful use-case...

Ok, PR asap.

Contributor

Tontyna commented May 17, 2018

Thats the interpretation I was hoping for -- especially when I contemplated accessing the page-context counters from document-context and vice versa.
What puzzled me the most was/is the consequence of this design: counter-manipulation in margin boxes is completely useless. At least I cant imagine a useful use-case...

Ok, PR asap.

@liZe liZe closed this in #631 May 24, 2018

@liZe liZe added this to the 43 milestone May 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment