Why do you need a portal? Usually, such a layout is based on the portal's table and the fields from the portal are listed in the body without needing the portal.
Can you describe the design of your layout in more detail?
In particular, what is the "sorted by" field specifed for your sub summary part?
Also, what is the relationship between the layout's table occurrence and that of the portal?
As always, you are right. I was making this too complicated. I used a portal because it negated the need for an explict find. Because of the joins I did, referencing an invoice number, produced a list of items associated with that invoice number and it was easy to display these items in a portal list.
I changed the layout to a simple list with a header and wrote a script to find items associated with the invoice# in the invoice table.
The layout I have now prints properly. I guess my problem is not understanding what prints and what doesn't. Pointers to the documentation on this topic would be appreciated.
Layout that prints properly:
Header: Name of supplier, phone #, etc. (from a global user options table)
Stats from the find: number of invoiced items (found count), invoice number
Body: list of the items associated with the invoice
Thanks again for the good advice.
In theory, everything you see on your screen when in browse mode should print unless the object has the "hide when printing" property set in the inspector. Preview mode is usually a good predictor of what you'll get when you print with the "records being browsed option" selected. It can be misleading if you intend only to print the current record as it will preview your layout with the entire found set.