PDFView printWithInfo:autoRotate: fails

2019-07-06 21:06发布

问题:

I'm trying to print a PDFDocument that I am constructing from a series of images. In case it matters, I'm doing all of this from within a Mozilla plugin.

I create the PDFDocument, and put it into a PDFView, then I call

[printView printWithInfo: [NSPrintInfo sharedPrintInfo] autoRotate: YES];

The print dialog comes up (as a separate window, instead of panel. I assume that that comes from being inside a mozilla window, so I wasn't too worried about it. The dialog shows my document, and I can page through it correctly, and everything looks good.

However, when I hit "Print" the dropdown with "Layout" etc becomes empty, and the view under that becomes empty. The window doesn't disappear, and the document doesn't print. Hitting Cancel does exactly the same thing. The only thing I can do then is force-quit Mozillla.

I based the program off of PDFKitLinker2 from the apple dev site, and that program works. But I can't see any significant differences between it and my version.

Any suggestions on where to look?

thanks.

EDIT: Yes, I know that this is pretty much an exact duplicate of Printing Off-screen PDFViews but that never got a sufficient answer... (And I didn't notice it until just now...)

回答1:

Sounds like you have a memory management issue here. Have you checked the console log to see if there's an exception being thrown? How are you creating your PDFView?

But why not do it the way WebKit does it?

Specifically, declare a category on PDFDocument

@interface PDFDocument (PDFSecretsIKnowViaWebKit)
- (NSPrintOperation *)getPrintOperationForPrintInfo:(NSPrintInfo *)printInfo autoRotate:(BOOL)doRotate;
@end

Then when you want to print your PDFDocument simply get an NSPrintOperation from it and run it.

NSPrintOperation *op = [myPDFDoc getPrintOperationForPrintInfo:info autoRotate:YES];
[op runOperation];
// [op runOperationModalForWindow:delegate:didRunSelector:contextInfo:] if you have a window to attach it to


回答2:

This works for me too. I've verified that getPrintOperationForPrintInfo:autoRotate: exists and appears to work correctly on 10.4, 10.5 and 10.6.