• Replies 4 replies
  • Subscribers 103 subscribers
  • Views 1357 views
  • Users 0 members are here
Options
Related

Will auto loose-leaf ever remove/move a point page to the end of a range?

Christian Aviles-Scott

Hello everybody,

My company is starting to do updates #2 with XPP's auto loose-leaf. Some of the automatic choices are not consistent with our human compositors, especially surrounding point pages. We've seen point pages deleted when content is contracted and the point page is no longer necessary. My question is whether XPP will every remove a point page that would otherwise have content on it in favor of a point page at the end of the range of effected pages?

For example, update 1 of a particular title had pages ...15, 16, 16.1 (less than half full), 17, and 18...; all pages were full except for 16.1.

In update 2, page 16 had 2 lines added and page 17 had 4 lines added.

I'm experimenting with various ll_tries settings, but XPP always seems to give pages ...15, 16, 16.1 (full), 16.2 (full), 17, [18 deleted]....

Our human compositors would prefer the result to be pages ...15, 16, [16.1 deleted], 17, 18, 18.1...

Thank you for any insight or advice,

Christian Aviles-Scott

CEB (Continuing Education of the Bar)
Rate translation
×
Suggest better translation
×
  • Hi Christian,

    I don't have a real answer for you but I agree that your "human" results are the prefered sequence. In our environment we have a script that controls this and looks at ranges of pages that have been "amneded" and then composes the whole sequence in one Compose Range+ Group. We have other things going on that mean we have to use our own programming skills to control the final looseleaf composition whilst using alot of the auto looseleaf features.

    Chris
  • Christian,

    The one thing I am not understanding is that you seem to have a page 16.1 in update 1 but no blank page 16.2.
    In a normal page oriented looseleaf environment the expected sequence in update 1 would be page 16, 16.1, 16.2 [blank], 17.
    But that does not seem to be the case.

    And yet after the update page 16.2 does get created by the system...

    Now that being said I agree with Chris that one typically needs some extra processing after the initial looseleaf in order to rearrange things the way you like them to be.
  • Hi Christian,

    We have experienced the same issue and like Chris and Bart mention, looseleaf compose does what a machine thinks, not always same as us humans. :) So workflow scripts usually have to be used.

    I have found that it will determine the range to compose based on what page actually was updated, regardless of the existing folios and what would make more sense based on the folios.

    Here is what appears to have happened:
    Saw page 15 change and did a range compose of pages 15 and 16 and was able to fit all the data, so XPP is done with those pages.
    It then skips page leaf 16.1/16.2 because there were no changes.
    But the additions of 4 lines of text added to page 17, maybe caused overflow and then autocompose looks to apply the tries you have set up. It appears to me that it may have used a PreFol which then grabbed leaf 16.1/16.2 and XPP does not look back to determine the ideal folio output.

    The best we could do was setup the tries to do what we considered to be the best to cover our requirements, but it only takes you so far.

    Chris Cigno
    Thomson Reuters
  • Thank you for your replies, Chris, Bart, and Christine. I'll explore the possibility of creating a script to control the desired output. Have a great upcoming weekend!