I had to take another look at this one as I managed to see the problem again. The second issue seems to be related to the style of the PDF encoder with a do->... Our current code won't correctly pass the interrupt exception up the 'do' stack we end up with a page state that isn't correctly initialized.

Marking as fixed.

The test case is pretty specific, if they set a page fit mode then they see the black page, otherwise they do not. I can reproduce the problem only but only after putting a few debugger breaks on the AWT thread.

I'm pretty sure that it's possible that a a page initialization can be interrupted as various view settings are applied during the commonDocumentLoading() method call. There are various property change event that are fired during the document loading and with finer logging turned on an interrupt exception boils up from the the Form class. When the Form interrupt exception is thrown we don't mark the page as not initialized and on the next initialization request we have an empty Form object that won't paint anything. In PDF in question this results in no content being draw as there is a root form object that spans the rest.

I remember seeing something similar in the past but couldn't narrow it down. This test case seems to highlight the initialization issue.