Searching the entire web didn't turn up this one, so let me add it here for reference.
I was printing a book from Frame 7.1 (xm7.1b023) on Solaris SPARC 64-bit. This book contained, amoung other things, about 100 EPS screencap images totalling 2.7GB.
I was watching the .ps temp file grow from another machine, and just as the file size reached 2 GBytes, it vanished.
Back on the Unix workstation, the terminal window displayed:
fmprintdr.ps: Using /opt/apps/frame7.1/fminit
fmprintdr.ps: Cannot finish printing.
My conclusion is that 32-bit versions of Frame (which FM7.1b023 presumably is), cannot handle Postscript output files larger than 2GB. This could also be an artifact of the execution environment that 64-bit Solaris provides for 32-bit apps. The file system APIs are likely 32-bit limited, and apparently signed.
I wouldn't be surprised if this 2GB limit applies to .pdf print files and .fm component files as well, although they are unlikely to ever get as large as .ps files commonly do. I would expect this limit to be common to all 32-bit versions of Frame running on any 64-bit OS. You'd expect a 2GB limit for 32-on-32, and I'm not terribly surprised to see with 32-on-64. I was hoping for an unsigned 4GB limit.
The second work-around, which worked, was to batch re-sample the original PSD images to EPS files at the actual rendering res. That got the .ps file size down to under 800MB.
The first work-around, which did not work , was to open the book in FM9.255/Win7-64. That didn't even begin to generate a .ps file. It just silently did nothing. Since we'll eventually end up on this platform, I suppose I'll have to figure out what the problem is, and I can think of several matters to rule out.
Thanks for sharing. I have some files that are starting to approach that size. This is useful information.