Xymacro "PN" may not work properly with compose division by range

Just found that the xymacro "PN" may cause inconsistent result when compose the division by range. It is not alerted in the Xymacro manual.

For example: a division containing 6 pages. At the beginning of page 3, the <pn;4;1;1> inserted to change the page number on page 3 to "1" and the rest of the pages. If the "Compose Range for 2 pages" is executed on page 2, the page number of page 2 will be changed to "page 1" unintentionally.

Could anyone help to explain why it could happen.

Thank you

Parents
  • 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.

Reply
  • 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.

Children
  •  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