Simon,

That is happening because XPP will compose a bit of page 3 while it is trying to decide where to end page 2.
If your <pn;4;1> macro is sitting at the top of page 3, then it will get composed (and executed) during that action.

I think that this would not happen if you would have an hard coded <ep> in front of your <pn;4;1> macro.

And I also think that if you do a compose whole division, this problem does not occur (correct?)

One question I have: After you do the composition of the Range of 2 pages, if you then do Search > Find Errors on page 2 (you might need to do it repeatedly to cycle through all the errors) do you get a "Page numbering error" message?

From the little you've said about your sample division, I'm guessing that you may find that this is the case.

And if so, composition is telling you that under these circumstances it could not properly calculate the page number (and you end up with the same page number as the previous page, because that was its starting point for the page number calculation).

And under the circumstances of your sample (with the little that you have described), the page numbering problem could be very specific to having reset %p4 to 1 on page 3 of the division.

Why? Because normally you would not be resetting the %p4 page number unless you were also starting a new "section". Sections (for the purpose of page numbering) are defined by the %p1 through %p3 values. If %p1 through %p3 are unchanged, then composition considers the pages to be in the same "section".

Since you've not described any change being made to %p1 through %p3, all the pages in question are in the same "section". So, the page numbering logic sees that the previous page (page 1) is page number 1 and the next page (page 3) is also page number 1 and everything is in the same section and so it does not know what page number to assign to page 2.

So, even if nowhere in the division are the %p1 through %p3 values actually being used or displayed on pages, if the %p4 value is being reset to 1 then at least one of the %p1 through %p3 values should also be changed. Then the page numbering logic will have a much better chance of success when doing a Range composition.

From what I see of the code doing the page numbering logic, it all seems very complicated as it's also handling loose-leaf scenarios with insert pages. And I'm not sure that it's handling the Range composition scenario as well as it should. So there may still be a problem with the page numbering logic even if you also change one of the %p1 through %p3 values, but I think you will have a better chance of desired results if you also properly change one of  the %p1 through %p3 values at the same time as you reset %p4 to 1.

 Bart and Jonathan, thank you for your response.

This phenomenon can be replicated as follows:
With the Xyvision sample jobs :- JOB_xybase2

1) At the end of page No. 2, add in xymacro <ep>.
2) At the beginning of page No. 3, add in the xymacro <pn;4;1>.
3) compose whole division, the RelPg 3 will be changed to page No. 1.
4) set the curser on page 2, perform the Range Compose with Number of Pages that set to 2. Now the RelPg 2 will display page number 1.

For Bart, adding the <ep> before <pn;4;1> on page 3, the result is the same. But if the "pn" macro changed to <pn;4;2> or <pn;4;3>, then range compose seems working proper.

For Jonathan, there is no error found in the job.log and jobwork.log when referring to the above sample test.

The user encounters this issue recently because their clients give up the publications in hardcopy, instead they request the document to be outputted in softcopy only (PDF format). The clients also change the requirement of the publication as follows:

For example, the original division contains 9 pages. In production, a version would be requested to have the page numbers to be changed and set as 1,2,3,1,2,1,2,3,4.  During revision, more content could be added in the middle pages so that additional page would be added as 1,2,3,1,2,3,1,2,3,4.

As such, the operator thinks that the "Range Compose" could be used instead of whole compose.

As we do not have any experience in Looseleaf environment, I do not sure if the Looseleaf option could handle this.

Thanks again

Yes, the "Page numbering error" message is not written to the job.log or job.worklog files unless you are using Auto Loose-leaf mode. If not, you will only see this message when you do Search > Find Errors (in loose-leaf mode you also see an '*' next to a page number in the loose-leaf manifest as well to indicate this error).

Again, as I mentioned, since you are not also changing one of the %p1 through %p3 values at the same time as you are re-setting %p4 to 1 you are not really giving the page numbering logic a chance to work correctly (with the Range composition scenario).

If you don't want to do anything more than what you are already doing with your described scenario, then I suggest that you have your operators always do a Whole Division compose.

Another option would be to separate these different "sections" of the document into different divisions, and use Job Processing to put them together when you produce a PDF.

Hi, Jonathan,

Referring to the above Xyvision sample job, Xybase2, I try add in the section number with %p3 in the page number format as follows:

1) In the PL table, recto1 and verso1, the frill block content changed from [folio] to [pgnum]

2) In the ItemFormat table, the [pgnum] prestring changed as below:

   <la;15q>− <mc;%p3=0;nul;ri(%p3,%fmt3)><mc;%p1=0;nul;ri(%p1,%fmt1)><mc;(%p1=0)*(%p3=0);nul;ti(-)><mc;%p2=0;nul;ri(%p2,%fmt2)><mc;%p2=0;ri(%p4,an);ri(%p4,abc)> −

3) In the Division ticket, Multi-part page "p3" changed to 1

4) At the beginning of page 3, add in the macros as : <pn;3;2> and <pn;4;1>

After whole compose, the page number shows 1-1, 1-2, 2-1, 2-2, 2-3.....

However, if the the Range Compose is executed at page 2 and number of page = 2, the error still occurred that page number would be changed to "1-1"...

As such, adding the %p3 section value does not help.

We wish to know if there is any special macro to be set at the end of page 2 so that the page number can be frozen and it would not be affected by the <pn> macro.

Thank you in advance.

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.