Hi Simon,

Thank you for trying to see if changing any of the %p1 to %p3 values would help get correct results. I'm sorry that it didn't help with your specific scenario, but I think that it does make it less likely to get incorrect results if you do include doing that (from doing further testing of your "sample" I found that getting "incorrect" results all depends on exactly how many pages are Range composed and what is the starting page number of the range and where the page number "reset" occurs within the range - it's that complicated).

I do not know of any special macro to set at the end of page 2, so that the page number can be frozen and would not be affected by the <pn> macro.

As I said before, from what I saw of the code doing the page numbering logic it is very complicated. And then the code actually does a lot more calculating when using loose-leaf mode, as that is the scenario where it is expected that only ranges of pages would be composed (i.e. pages that have "changed"). And that extra loose-leaf code still depends on at least one of the %p1 to %p3 values changing when %p4 is "reset". But it doesn't do that extra stuff if not using loose-leaf mode, and obviously the code is not handling the Range composition scenario as well as it should when not using loose-leaf.

Unfortunately, we don't have a high level of confidence that we would be able to "fix" the page numbering logic/code (in non-loose-leaf scenario) without breaking it in other scenarios. And realistically we're concerned that if we try to revise this code, that we won't know until much later that we broke it in another way.

So as I mentioned before, given your scenario of wanting to have a page number "reset" (or multiple resets) within the same division without using loose-leaf mode we recommend that you have your operators always do a Whole Division compose (and if you have them do that, then it should not matter that you don't also change one of the %p1 to %p3 values). Or separate these different "sections" of the document into different divisions, and use Job Processing to put them together.

Hi Simon,

Thank you for trying to see if changing any of the %p1 to %p3 values would help get correct results. I'm sorry that it didn't help with your specific scenario, but I think that it does make it less likely to get incorrect results if you do include doing that (from doing further testing of your "sample" I found that getting "incorrect" results all depends on exactly how many pages are Range composed and what is the starting page number of the range and where the page number "reset" occurs within the range - it's that complicated).

I do not know of any special macro to set at the end of page 2, so that the page number can be frozen and would not be affected by the <pn> macro.

As I said before, from what I saw of the code doing the page numbering logic it is very complicated. And then the code actually does a lot more calculating when using loose-leaf mode, as that is the scenario where it is expected that only ranges of pages would be composed (i.e. pages that have "changed"). And that extra loose-leaf code still depends on at least one of the %p1 to %p3 values changing when %p4 is "reset". But it doesn't do that extra stuff if not using loose-leaf mode, and obviously the code is not handling the Range composition scenario as well as it should when not using loose-leaf.

Unfortunately, we don't have a high level of confidence that we would be able to "fix" the page numbering logic/code (in non-loose-leaf scenario) without breaking it in other scenarios. And realistically we're concerned that if we try to revise this code, that we won't know until much later that we broke it in another way.

So as I mentioned before, given your scenario of wanting to have a page number "reset" (or multiple resets) within the same division without using loose-leaf mode we recommend that you have your operators always do a Whole Division compose (and if you have them do that, then it should not matter that you don't also change one of the %p1 to %p3 values). Or separate these different "sections" of the document into different divisions, and use Job Processing to put them together.