Groupdocs Viewer 8.0.7 - Wrong page no displayed initially during server delays to return pages

@sachinerande

Thank you for reporting this issue. When testing the latest changes of the UI on a dev environment I have observed similar behavior. In my case it was stuck at page 18 while I was on page 1.

We’ll analyze this issue and update you.

1 Like

Great ! would be really great if can be sorted quickly. Thank you @vladimir.litvinchik,

@sachinerande

You are welcome! As soon as we get this issue fixed we’ll let you know.

1 Like

@sachinerande

We have fixed this issue in the latest version of GroupDocs.Viewer.UI package version 8.1.1. See complete list of changes in this release at Release 8.1.1 · groupdocs-viewer/GroupDocs.Viewer-for-.NET-UI · GitHub.

To get the latest version you have to update you package references and set version to 8.1.1 in your csproj file.

1 Like

Thank you @vladimir.litvinchik for fixing this, will run it through test cycle, and let you know.

1 Like

@vladimir.litvinchik Just did a quick tests and it appears following things are not working as expected on 8.1.1.

Issue 1 - workaround given on link is not working. i had to replace like below, to let it work.
string basePath = $"/{apiMethodName.TrimStart('/')}";
with
string basePath = $"/viewer-api/{apiMethodName.TrimStart('/')}";
frontend doesn’t appear to supply the custom api endpoint “viewer-api” like it did in 8.0.7 while making get-page call.

Issue 2 - This is about broken print functionality.

  1. In the above code given set the options.PreloadPages = 2;
  2. Run the solution, and opened doc in viewer with 155 pages. (you may open any lower say around 10 pages, though i didnt check)
  3. From the thumbnail scroll and click on page no. 5
  4. let the page page 5 and 6 to load. Click on Print button. The print window is stuck like shown in image and javascript error popsup in the console. see the image below.

image.png (156.9 KB)

Issue 3 - The numbers on print window doesn’t change as were before. To reproduce follow steps below.

  1. Open any document with preload page count as 2.
  2. Once document is opened just click on print button. Wait for sometime and notice the number 2 “Loaded 2 out of 250 pages” keeps there. It doesn’t change. Its expected to increment as the pages gets loaded.
    It was incrementing before on the 8.0.7 viewer.

Issue 4 - Viewer has now animation around when scrolling across pages. When say i am on page no. 1 and i go to page no. 300, there is redundant scrolling effect, is that possible to disable that with some settings ? This is not a blocker but wanted to highlight, to make it configurable.

@sachinerande

Thank you for sharing you findings. It looks like not all the changes were properly merged. We’ll review all the issues and update you.

Great, thanks @vladimir.litvinchik , I will await next fix.

1 Like

Hi @vladimir.litvinchik just following on this, when do you think those reported ones would be fixed ?Thanks.

@sachinerande

At the moment we have fixed two of the issues. We plan to publish the version with the fixes next week.

1 Like

@sachinerande

We’re still working on the fix, and it’s taking a bit longer than expected to ensure everything works correctly. We expect it to be ready in the next couple of days. We’ll keep you updated as soon as it’s resolved.

1 Like

@vladimir.litvinchik just wanted to check if any updates on this ?

@sachinerande

I’m sorry for the delay. Unfortunately, I can’t publish the package at the moment due to the issue with the code signing certificate on the vendor’s side while the changes are already merged, see this PR for more details.

Let me share the details on each of the issues you’ve wrote about:

  • Issue 1 - base path
    With 8.1.2 you won’t need the workaround, I have tested and it worked well without custom URL builder

  • Issue 2 - print functionality
    Fixed in PR.

  • Issue 3 - print functionality
    Fixed in PR.

  • Issue 4 - disable scroll animation
    The PR adds new option EnableScrollAnimation which you can disable

    builder.Services
       .AddGroupDocsViewerUI(config =>
       {
           config.EnableScrollAnimation = false;
       });
    

As soon as the issue with the certificate is fixed we’ll publish the packages and update you.

Hi @vladimir.litvinchik, Thank you for the update and various fixes. Kindly notify whenever the package would get published.

1 Like

@sachinerande

I’m sorry for the delayed response. GroupDocs.Viewer.UI package 8.1.2 that includes fixes I wrote about in my previous comment.

See the release notes for more details about the fixes: https://github.com/groupdocs-viewer/GroupDocs.Viewer-for-.NET-UI/releases/tag/8.1.2

Have a nice day!

Hi @vladimir.litvinchik , no problem, Thank you for the update. I will run through test cycle in few days and let you know.

1 Like

@vladimir.litvinchik Just did a quick check, but seems fonts are not coming through. It shows like below.

image.png (8.6 KB)

@sachinerande

The fonts are local now, can you try cleaning up browser cache?

@vladimir.litvinchik - It was the media middleware issue which was intercepting, so that’s now resolved. Other mentioned 4 issues are now sorted. Thank you.

Problem #1
With 8.1.2 - Letter size pdf pages are not fully visible on 100% default zoom level (need to scroll). Also There is no intermediate zoom level between 50 and 100 that we can explicitly set.
Previous 100 percent on 8.0.7 was properly resizing the page (no need to scroll)

Note - We load the viewer within iframe as below within cshtml file.

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

Viewer_8.0.7_LetterSizePage_FullyVisibleOn100PercentZoom.png (29.6 KB)

sample_letter_size_5pages.pdf (3.7 KB)

Viewer_8.2.1_LetterSizePage_NotFullyVisibleOn100PercentZoom.png (36.4 KB)

I have attached screenshots and sample pdf for reference

Problem #2 -
Issue #1 still exists when ran on azure app service, as it still uses azure’s hostname (suffixed with azurewebsites.net rather than what user has entered in url bar.).

I have added workaround suggested on following again and change in buildUrl method as below so it takes relative irrespective of the domain and what domain user typed in web browser.

            string basePath = $"/{apiPath.TrimStart('/').TrimEnd('/')}/{apiMethodName.TrimStart('/')}";
            var queryString = BuildQueryString(values);

            return string.IsNullOrWhiteSpace(queryString) ? basePath : $"{basePath}?{queryString}";

Could you please check the issue again and fix?

@sachinerande

Thank you for sharing this issues. I’ll double-check path issue first and update you.