Printing large portals (50 rows or more)

[ddreese]

We recently had an issue with printing on of our layouts. I had the portal set to 50 rows max, reduce size of enclosing part to shrink it up. It turns out because of some data quality issues (old, imported inaccurate data) I needed to have to set to about 250 max rows for the one printed portal.

So I got that taken care of and everything printed fine expect the first page of the layout. The first record from the portal printed, then proceeded to skip the remaining records on the page. Once page two printed, everything was back to normal. To get it to print the first page correctly, I had to put the portal rows back down to 50. So then I combined that first page with the next 5 pages of printouts to get a correct printout.

Anyone else have this problem? It won't be an issue anymore soon, but who knows when it will happen again. Thanks!

[DykstrL]

Portals were not designed or meant to be printed. I don't think you will ever get good results. I had a similar problem where I I had to limit the portal rows to 36, otherwise I had all sorts of problems - different each time. Even limiting to 36 rows, I would occasionally get goofy printouts, like clipped text, lines cut across pages, and others.

I recommend going to the related file and printing from a layout there using standard fields or, even better, merge fields. Your results and printouts will be more consistent and better controlled.

[ddreese]

Thanks, I didn't know portals had such problems with printing. The problem is the printout has to print from three different files, having three seperate layouts that print could be a huge waste of paper in some cases. I guess I'll suck it up in the meantime. Thanks for the reply!

[RalphL]

There is another method, the Troi Text Plug-in has a function SumText. This will give you a calculated field that contains the same information as a portal. It can use sliding to reduce the blank space on your page. It take a little effort to get a good looking layout. I have one such layout where the first part is 4 columns of 2 items each and the second part is 3 columns of 3 items each. They are sized so that if both or maximun size they fit on one page. I have done some where the second part is divided into 2 fields and one is printed on the first page and the other on the second page.

[Dan Burgess]

I believe this is related to this FileMaker TechInfo article: http://www.filemaker.com/ti/109359.html

"RESOLUTION:

Currently there is no workaround for this issue other than to avoid combining sliding text objects and portals on a multi-page layout."

I've found that I don't get problems if:

a) the portal is the only object in the part, even if it has a large number of rows. However, stick anything below the portal in the part and you get huge amounts of blank space.

: the portal does not cross the page break marker

c) the number of rows of data to be printed is close to the number of rows for the portal on the layout.

One part of a solution is to have each portal in the layout in a separate part. Instead of using just the body part, you can have three parts for each record. The trick is to first have a leading sub-summary part by the record's primary key, then the body part, then a trailing sub-summary by the record's primary key. Put one portal in each of these and don't forget to have a sort order with the primary key as the last entry.

The second part is to have layouts with different numbers of portal rows and choose the layout that is the closest match to the number of rows to be printed. This seems to work for portals that cross the page break marker as long as there are enough rows of data to fill the portal.

This has worked so far for me, but as ever, YMMV.

Hope this helps somebody, regards

[Dan Burgess]

I believe this is related to this FileMaker TechInfo article: http://www.filemaker.com/ti/109359.html

"RESOLUTION:

Currently there is no workaround for this issue other than to avoid combining sliding text objects and portals on a multi-page layout."

I've found that I don't get problems if:

a) the portal is the only object in the part, even if it has a large number of rows. However, stick anything below the portal in the part and you get huge amounts of blank space.

: the portal does not cross the page break marker

c) the number of rows of data to be printed is close to the number of rows for the portal on the layout.

One part of a solution is to have each portal in the layout in a separate part. Instead of using just the body part, you can have three parts for each record. The trick is to first have a leading sub-summary part by the record's primary key, then the body part, then a trailing sub-summary by the record's primary key. Put one portal in each of these and don't forget to have a sort order with the primary key as the last entry.

The second part is to have layouts with different numbers of portal rows and choose the layout that is the closest match to the number of rows to be printed. This seems to work for portals that cross the page break marker as long as there are enough rows of data to fill the portal.

This has worked so far for me, but as ever, YMMV.

Hope this helps somebody, regards

[Dan Burgess]

I believe this is related to this FileMaker TechInfo article: http://www.filemaker.com/ti/109359.html

"RESOLUTION:

Currently there is no workaround for this issue other than to avoid combining sliding text objects and portals on a multi-page layout."

I've found that I don't get problems if:

a) the portal is the only object in the part, even if it has a large number of rows. However, stick anything below the portal in the part and you get huge amounts of blank space.

: the portal does not cross the page break marker

c) the number of rows of data to be printed is close to the number of rows for the portal on the layout.

One part of a solution is to have each portal in the layout in a separate part. Instead of using just the body part, you can have three parts for each record. The trick is to first have a leading sub-summary part by the record's primary key, then the body part, then a trailing sub-summary by the record's primary key. Put one portal in each of these and don't forget to have a sort order with the primary key as the last entry.

The second part is to have layouts with different numbers of portal rows and choose the layout that is the closest match to the number of rows to be printed. This seems to work for portals that cross the page break marker as long as there are enough rows of data to fill the portal.

This has worked so far for me, but as ever, YMMV.

Hope this helps somebody, regards