Testing Documaker 11.5.4, I noticed something odd when I attempt to use overflow with a print control setting checked (Front Only, Back Only, etc.). If you look in the NA/POLFiles, sections marked with that kind of overflow still show up on every page. For my example, I had a section set to Front Only and another set to Back Only in the header. I had enough overflowing detail that this yielded two pages. From a print file standpoint, everything looks fine. In the NA/POLFile, both sections appear on both pages. The only difference I note is the presence of a PCTRL value on the NA line for each of these sections in the NAfile. Since the output comes out correctly, that isn't necessarily a problem, but it is confusing to see things in the POLFile that have recipients that do not print. It seems to be equallly confusing to RP, as I get a postiive hit when I log whether or not a second occurrence of either section is in the formset. Is this a desired behavior? Is anyone else having issues with it? There are times when we have some interesting header/footer requirements with overflow situations that necessitate DAL scripts to populate values in the correct fields, and I'm a little wary of modifying complicated (but working) solutions in favor of this slightly more confusing one. Thoughts?
Have you tried the stub options. The stub option as designed to allow the combinations of headers and footers (odd/even and the like that were common in Documerge). You do need to be careful with this if you are setting up grouping it currently does not work with grouping - this is a complex pagination (the stub processing) and grouping overrides it. There are ways to work around it, but without knowing your forms hard to give a good example.
The Stub should be in the version you have.
When you are using the front only and back only options, you also need to consider what you are telling the system to do. It will try and insert the controls you tell it to do but at the same time, will try and duplex. The front only and back only do not work in conjunction with duplexing especially when you have overflow involved. Thatis what the stub procssing does.
First you have to realize that these headers and footers are flagged as Copy on Overflow. That means for every page created the sections are copied over. And such sections normally always show the same content - minus page numbering fields or something the system might change during print. These print-control options are simply determining when the sections actually print - not when and where they get copied.
Also remember that with recipients, not every recipient has to get every page of a form. So, what is page 1 (the front page) for one recipient, might not print for the second recipient - in which case the second page might be page 1 (the front). Also remember, even with a single recipient, a section can have a copy count that could cause the section page to print a second, third, or whatever time. Each pass through, this page might be a front, back, even, odd, or last page.
This is why the copy on overflow sections appear on all the pages. The print-control only determines when they actually print.
I agree with your statements about Copy on Overflow and realize that multiple recipients in a formset could produce some unusual behavior, but I think that just illustrates a further complication of the situation I've described. If I have to use a script to populate a value on one of these overflowing sections, a different occurrence behaving as a front makes the situation even more complicated than I had described - can't just do odds or evens, for example.