Portals and printing don't generally go together. Standard practice is to base the report on the child layout to avoid using portalls for printing. Because no, they really don't slide reliably (as well as having other issues, like running out of rows if the number of related records is too large).
It sounds as though you've resorted to multiple single-row portals strictly to solve the sliding problem. If that's the case - and you don't have to isolate specific related records for some other purpose - then I would recommend you simply base your report on the related table and use a List view. This should solve the issue much more easily for you.
Cheers for the reply, unfortunately we are talking about a number of child tables. The PDF is for a logistics application, it prints an itinerary, each parent record is a day in the period of the trip and the children are all of the various activity types that we need to record and present. The itinerary will be built from a series of parent records so each bit of white space may be multiplied a dozen or more times, hence the original solution of individual rows each sliding up.
So I haven't just missed the advent of the sliding portal then? I am considering writing some apple script to export to PDF, open in Preview and export as PDF as this appears to work. Seems like a really laborious way to do something that is supposed to be supported however. Another option that has occurred to me: taking all of the data for the itinerary and putting it back into our FMP 12 solution only for printing, this also seems very sub optimal.
Any other thoughts?
Virtual List. This technique was designed specifically for the situation you describe.
And no, you haven’t missed the advent of the sliding portal. A portal is a device for data entry and display, not printing.
Would a sub-summary report based on your Parent table work?
If the data in the Parent table is a date, this could be your sort field for the summary report.
The data displayed from the various child tables could be displayed within the summary section.
If it’s half a dozen different related tables then stack the required fields from each related table and have them set to slide up.
That would only catch the first related record. The OP’s requirement is to pull multiple related records.
I haven't used the virtual list method previously, I will look into it and get back to you on how I go, thanks for the advice.
Yes of course, sorry...
No worries. Would be a good idea otherwise.