Well, the problem I see is that you look like you are talking about running the report multiple times; each successive run could/would have additional mailing labels, but you don't want to print the labels that were already printed from the first (or previous) run. Is this correct?
I'm fighting some sleep depravation, so bare with me... there might be a better solution. However, the only one that comes to mind is putting a parameter on the report which would signify where to start.
With your example, 7 labels are on the first run of the report; the next run of the report would then have a parm. that would allow the user to input where to start: label #8. You would then use this in logic in the Fetch() to do one of two things:
1. Ignore the first 7 records (parameter - 1), and also use this to determine where on the page (in the flow) to start printing new records/labels (knowing the location of each label on the flow would be necessary).
2. For the first 7 records (parameter - 1) send blank rows to the report, then fetch the remaining records as normally would be done.
This second option "should" allow nothing to be printed overtop of the previous printing, and to start where you left off before. Beware, this is untested!
As far as setting some variables which Actuate could pick up on for the next run(s) of the report, no easy thing comes to mind. You would essentially have to have this in a .bas file, and modify the bas file during each run... and I'm not sure that's even possible.
On the other hand, if there was a database column to hold this info... you could write to the database each successive run and update that field -- but the logic to keep this in line, so that you're not wasting resources after it becomes multiple pages, and .... it could get nasty, not to mention performance. You'd have to hit the db to get the data, then do it again to update. A whole new can of worms there.
Again, sorry if any of this is incoherant.
Good luck!
Bill