Groupdocs viewer for .NET - original pdfs returned to browser on clicking Print button

I am using chrome, but have seen same empty page in edge browser as well.

@sachinerande

When I was testing the iframe was not visible. We’ll try reproducing this behavior.

@vladimir.litvinchik
Iframe was not visible to me as well, I was just looking the source in browser developer console, to investigate this, and noticed iframe is created which is used for printing.

Let me know if anything needed from me to repro the 4 issues above. thanks!

@vladimir.litvinchik
please find below sample printed pdf (1 page) from chrome and edge browser, they both contain the additional empty pages when doing print from viewer.
sample_printed_edge_browser.pdf (82.0 KB)

sample_printed_chrome_browser.pdf (103.8 KB)

@sachinerande

Thank you for attaching the files. I can reproduce this issue. Will update you as soon as fix it.

1 Like

@sachinerande

Please try updating to GroupDocs.Viewer.UI version 6.0.22

<PackageReference Include="GroupDocs.Viewer.UI" Version="6.0.22" />

It fixes a couple of issues that you’ve wrote about.

  1. No extra pages. The screenshot shows print preview for a document with 30 pages.

  2. Added popup to show progress on pages loading.

  3. Page orientation is set to portrait or landscape based on first page dimensions.
    Which is not ideal but should work in the most of the cases.

Unfortunately, I can’t reproduce the issue where you can see the iframe itself since it is expected that iframe is hidden.

The issue where print preview appears on the second click should be also fixed.

Please check if it works as expected on your side.

1 Like

Hi @vladimir.litvinchik, Thank you very much for fixing the issues.

Here are the few observations.

  1. extra/empty page issue - SOLVED - this has been fixed for sure. I didn’t notice it appearing.

  2. all pages not printed in first attempt - - APPEARS RANDOMLY BUT RARE - this issue was randomly seen today but very rarely appearing. Once it occurs it remain consistent for that pdf and print window shows only few pages out of all pages available for printing. I have to open another document in viewer and then do print on it and again open the same document, and it resolves. I could not reproduce consistently this issue, but it happens for one of the pdf whenever I open the developer tools window (just pressing ctrl+shift+c on chrome browser) closing this window goes away. but it only happens for some pdfs. (the issue noticed on edge browser as well)
    please try out if you can produce this at your end or any clue if you can get for this, unfortunately i can’t product it as it’s bit random.

  3. popup visible after clicking print button - SOLVED - this appears to work correctly. This is really useful from user perspective. thanks!

  4. some print customizations - header and landscape view. - I managed to get this working by hooking my code like below. I think you can remove the @page style to be auto and it allows printing in both portrait and landscape mode. would that be feasible for you to remove that style so user can choose the best mode they want ?
    image.png (41.7 KB)

  5. small observation about the page number appears on viewer. e.g. open the pdf with 40 pages. goto last page (i.e. 40). viewer shows (40/40). Open another pdf of say 12 pages. Viewer shows (40/12). This is bit confusing. would be good if you can fix this.

I am going to provide the release to testers as it’s looking quite stable except point 2, and will report if anything found. Thanks again.

@sachinerande

Thank you for the feedback. We’ll try to reproduce the issues that you’ve found.

1 Like

@sachinerande

The lates GroupDocs.Viewer.UI* packages version includes fix to this issue:

  1. small observation about the page number appears on viewer. e.g. open the pdf with 40 pages. goto last page (i.e. 40). viewer shows (40/40). Open another pdf of say 12 pages. Viewer shows (40/12). This is bit confusing. would be good if you can fix this.

I have also set @page style to be auto as you suggested.

Se complete list of changes in the release notes.

Unfortunately, I have failed to reproduce the issue all pages not printed in first attempt.... In case you have some additional observations it may help to locate the issue.

1 Like

@vladimir.litvinchik - Thanks for fixing the additional 2 issues.
For the one that not reproduced, please find details below of my investigation.

We render the viewer within a html file using iframe calling the viewer url “/viewer”.

<iframe src="/viewer?file=somefilepath"
            name="targetframe"
            allowTransparency="true"
            scrolling="no"
            frameborder="0"
            style="height:1200px;width:100%;">
    </iframe>

It randomly gets reproduced when the scrolling is done between frame’s scroll bar (where doc is visible) and the outer scroll bar of html page within which iframe is rendered. This is rare but issue is linked to the scrolling doc and actual html page. may be this could help to repro.

@sachinerande

Thanks for the details. We’ll try reproducing it this way.

1 Like

Hi @vladimir.litvinchik
I just validated the fix, auto @page style works as expected, and users can now print in both portrait and landscape.

just about the title of the print document it appears as “Print Preview nameoffile.pdf” is that customizable, as we render it within an html page using iframe and would like it to be the title of the html page (i.e. parent html page’s document.title).
This is not a blocker as I already done with the script customization on print-window. but would be good to have that from product directly.
Thanks!

@sachinerande

Thank you for the feedback.

This is not a blocker as I already done with the script customization on print-window. but would be good to have that from product directly.

Sure, I will take a look at this issue.