We are sorry to hear that you have this issue. Can you tell us a bit more about this issue? It occurs especially with PDF documents, or with others too? On the screenshot we also see watermark and rotated page. The issue is still present, when these factors (rotating and watermarking) are disabled? We also don’t see a standard GUI on the screenshot, have you disabled it?
Can you, please, provide us a source code of the GroupDocs.Viewer widget? And also to describe sequence of your actions?
- It ocurrs only with PDF.
- PDF with/without watkermark or with/whitout rotated pages.
Thanks for providing us the code, but we unfortunately cannot reproduce the issue using your source code. About the “standard GUI” phrase, which I’ve asked - the question is removed now; I figured out that you are using the Google Chrome, and a Google Chrome toolbar is present on a screenshot.
I used Google Chrome and “Print” button is active, as you can see from the screenshot below.
I googled a little and found out that this issue may be caused by different reasons like plugins and so on. So I want to ask you the next things and then report the results here:
1. In the Google Chrome are you able to print the document using a “Ctrl + Shift + P” combination?
2. What about other browsers? Are you able to reproduce this issue there and if yes, then how it looks like?
Thanks and waiting for your reply.
- No, I’m not able.
- Yes, I am (attachs included)
Thanks for your reply, now we can see, that this issue is not related with specific browser, but rather with all browsers.
We suspect that this issue may be related to the some specific system configuration and settings, which are not associated with the GroupDocs.Viewer. It is very unusual and non-believable, that GroupDocs.Viewer is a reason of such issue. Because, in fact, when the option “.UsePdfPrinting()” is enabled and you click the “Print” button, server returns pure PDF document with “application/pdf” content type, and nothing more. And from this moment, when a browser has obtained a PDF-version of the document from the server, the GroupDocs.Viewer and a server at all have nothing to do with what happens next. All that will happen at the next step depends on how the browser will handle the PDF file.
To verify this you can try to open the same page on another machine, for example (but you should be careful - that another computer can be configured also with the same option). Or you can try to print some another (not related with the GroupDocs.Viewer) PDF file from the browser.
It is possible to get the url for the pdf that is printed using the “UsePdfPrinting” function?
We are thinking on ask you to do or do it ourself, an applet that prints this pdf.
Please send me your comments.
I’m sorry but, to be honest, I cannot understand, which URL you need. maybe, there is some misunderstanding; now I’ll try to explain and answer, and then you will clarify your question.
There are two printing modes: standard printing (or HTML-printing) and PDF-printing. These modes are controlled by the “UsePdfPrinting” method:
“.UsePdfPrinting(false)” (or method is not specified) - standard mode;
".UsePdfPrinting(true)" - PDF mode.
Thanks and waiting for your reply.
i was referring to the pdf-mode, as you say when you click the “Print” button the viewer, uses an url like “http://domain/viewersite/document-viewer/GetPdfWithPrintDialogHandler?path=temp\S\106_1.docx&watermarkText=+&watermarkColor=0&watermarkPosition=TopCenter&watermarkFontSize=0&useHtmlBasedEngine=true&supportPageRotation=true” to get the pdf.
To get off the problems of depend if the browser is able to display the PDF document, we are thinking on use another web page that will have an applet that will use this url to print the pdf directly.
In your opinion, how do you think about this solution?
I’ll would be glad to hear your comments.
Well, if you do need such functionality, you are welcome to use it. This link is idempotent, it “holds” a GET-request, and its result depends on the GET-parameters, and only on them. By using this link and passing the specific desired parameters like document name, you can obtain a PDF-version of any existent document. The only requirement - the cache should exist for the requested document. It is not necessary to open the document just before using this link; the document can be opened a long time ago and even by another user. In other words, the “GetPdfWithPrintDialogHandler” HTTP-handler cannot generate the PDF-version of a document, it can only deliver the previously generated file.
But, again, this link will only provide you the PDF-version of the document and nothing more. How to print this document - depends on you and your environment. For example, you can save this PDF, open in Adobe Reader (for example) and print. Or print from the browser, if browser can open a PDF.
how are you?
It is possible for you to implement an api function to return this url, relative to the document displayed by the viewer?
My idea is, having the document opened by the viewer. Invoke this new function and get the url, and then, print the document.
I’ve managed to get the url using:
Sure, we will review this request and will let you know about this.