Auto Compose and revision field in JT?

XPP version 9.4.1 - using xml specs - Hi  ... I have a looseleaf product that restarts at update1 each year which poses a problem when update number starts to repeat and using auto-compose there is no way to tell it to only compose the current year's update. Looking at the JT there is an option to set a revision number; however I don't think auto-compose can reference that when determining what pages to compose. I have hunted the documentation but not looking good. Has anyone else had to manage this type of looseleaf cycle and if so are there any tricks to making this work? 


  • Hi Bart, 

    Each year the update number restarts at 1 and the release number increments by 1. The release line in the folio block reads and outputs the update number and month year fields from the JT and DT which is how the reader knows which year the update is from.

    I have actually come up with a way to make this work in our script. After the toxsf function completes which only updates the pages found by xydiff I am updating the manifest using divflags -dc -y > dflags.99 command and changing all the pages with the current update number being processed to update #99. This JOB only has 52 updates per year. Then auto-compose is run which will now only compose the marked pages and not include the pages from previous year unless changed. When that is successful, I reverse the manifest and turn off auto in the Job Ticket. We will have to make our users be very conscious of the date fields in the manifest when they perform manual corrections.

    Ideally we would like the autocompose to realize the release field of the JT and a column in the manifest that reflects the release number as well as update number.

  • Christine,

    As you have found out yourself, XPP makes a distinction between a revision and an update. When you up the revision number, you are supposed to recompose the whole document and eliminate all update pages. 
    This is obvious from the XPP page manifest as it only shows update numbers (and dates).
    And you also found out that it is very confusing for XPP to re-use the same update number.

    Here is what I would do:
    Since the update number can grown up to 9999 and you only have 52 updates a year, I would grown the update number by 100 every year. So you start year 1 with update nr 1 to 52 and year 2 you run updates 101 till 152.
    And in your styles specs (and all other places where you have to write or read the update number) you recalculate the %updatenr to get the correct one (I don't have to spell out how:-)
    Like that you have system that will work for the next 100 (or is it 99?) years :-) 

    Would that work?

  • Hi Bart - thanks for the suggestion and yes I think that would work too, however I have committed to the method I described which has been changed in that I will leave the previous years update at 99 during the production cycle and then return it to original number in prep for next update cycle. I do like your idea for the sake of the XPP operator it would be easier to differentiate which number belongs to which year so maybe I can re-evaluate for next year and apply your method. 

    Thanks much!

Reply Children
No Data