I was trying to come up with an elegant solution to this problem a few weeks ago. There were two problems that I was trying to resolve. The first one is the one that you mentioned, eliminating the pause button. The second problem was that our dreaded Windows users were being taken out of full screen mode when the preview window opened.
Instead of taking the user to a preview window I ended up writing a script that would create a PDF and stick it into a global container field... and then display the PDF in a global popover window. What is cool about this technique is that I you can put buttons in the popover that trigger whatever scripts you want. My users also seem to like viewing their Invoices, Quotes, etc., as PDF better than viewing them in the preview window.
I am running the solution on a server and it's creating the PDF files and putting them into the container is a split second.
I do have this situation here and there; if on a mac I use the print with "open pdf in preview" option, which leaves Filemaker as it is and transfers the burden to Preview; Preview shows the page(s) and sports the "cancel" and "print "buttons at bottom right of the window. Control goes to the user, he can cancel and reselect the FM window.
Check it out, it might fit your needs.
We used this technique prior to the new windows script commands which allowed us to have a palette like window.
Downside of the keyboard shortcut approach is the user friendliness and intuition. People are confronted with a preview and no hint about what to do now.
We even had a special preview menu set offering menu commands for going forward, backward, printing or aborting, but people didn´t see it or find it.
Worst case were people thinking, that the app crashed, since they managed only to hit keys which didn´t have a function. They force quit the app.
So at least you need good documentation for this approach and users who can read ...
Only it doesn´t work with runtimes at least on Windows, since you can´t programmatically create a PDF.
And I sometimes saw problems on Windows machines where a prior written PDF couldn´t be overwritten. But using a new name for every printed PDF isn´t a solution either, if you don´t want to fill the user´s harddisk quickly.