Emails not rendering correctly in 18.6.1

GroupDocs.Viewer Product Family
6

Hi Usman,

My boss wants to know if this issue is being treated as a priority?

I haven’t got a reasonable work-around since we want to generate the HTML files in advance for our customers (and save them waiting) and we have about 170,000 emails in our system to re-cache.

I would go back to the working version but that had an issue when generating the cache on multiple threads (error accessing vs.bin) - to process 170,000 in a reasonable time we need to be able to generate them in parallel.

Please advise on the priority to fix this issue in the backend viewer API and any expected timescale for the fix.

Thanks,
Darryl

7

@dbaker1,

Thanks for coming back to us.

Currently, the issue is under investigation and not being treated under the Priority Support. To raise the priority of the issue, you will have to purchase and avail the Paid Support Services.

8

Hi Usman,

I’ve just asked my technical director if we are paying for support - he says we are paying a lot more than the listed price for the viewer on your website. Please can you tell me how to check what our subscription actually includes?

9

@dbaker1,

Thanks for your response.

In case you have purchased the Paid Support Services, you’ll be able to access the Paid Support Helpdesk and create the tickets in it. For more details about your subscription, please feel free to create topic in GroupDocs.Purchase category.

10

@dbaker1,

The issue you have found earlier (logged as VIEWERNET-1646) has been fixed in this release.

11

Hi Usman,

I finally managed to testing this fix. I updated the Modren UI app to use the current nuget package - 18.8.0 and the problem still occurs.

I deleted the cache before trying it again.

Please note that I had changed the Modren UI demo code to use embedded resources, but I removed that change and tried it again got the same result.

I also had to update the Modren UI code to build without errors as there were breaking changes to the GroupDocs API that have not been reflected in your example project.

Please investigate this again - if it works correctly for you, then please point me toward the exact source code that you have verified it with as it seems that not all of your sample code is being updated when new releases come out.

Regards,
Darryl.

12

@dbaker1,

Thanks for coming back to us.

We apologize for the inconvenience. We investigated your reported issue with the latest version of the API and found that GetPages method is generating only 1 page, however, GetDocumentInfo still returns the count of the pages as 5 which is causing the issue in the front end application you are using. We have noted this behavior at our end (logged as: VIEWERNET-1738) and shall investigate it further.

We have logged your request to upgrade the version of GroupDocs.Viewer in the front end application as Update application for GroupDocs.Viewer for .NET 18.8 · Issue #30 · groupdocs-viewer/GroupDocs.Viewer-for-.NET-MVC-App · GitHub. We also recommend you to please have a look at the release notes to know about the changes in the latest version.

As a temporary workaround of your issue, please comment out the following line in Controllers/PageHtmlController.cs. For reference, you can download the updated application from here.

Line: 30  options.PageNumbersToRender = pageNumberstoRender;

Hope it helps.

13

Hi Usman,

The workaround doesn’t work properly - removing that line stops it generating the other 4 pages, but the user interface still thinks there are 5 pages. The navigation controls show page 1 of 5 and there are 4 blank pages shown.

I’ve checked this with the latest version 18.9.0. Please can you confirm that the issue is still being tracked since VIEWERNET-1646 was noted as fixed in 18.7.

Thanks,
Darryl

14

@dbaker1,

Thanks for coming back to us.

The reason behind this behavior is that GetDocumentInfo method is still returning the count of pages as 5 (as mentioned in this post) and the navigation controls and page containers in the front end UI are created based on the information returned by GetDocumentInfo. Please note that this behavior was fixed for GetPages method in v18.7, however, the issue with GetDocumentInfo (logged as: VIEWERNET-1738) still exists and we are currently working to resolve this issue. Hopefully, the fix will be shipped with version 18.10. We shall keep you notified in case of further updates.

15

Thanks Usman,

As it was only partially fixed in 18.7, when I found it wasn’t fixed in 18.9 I thought it best to ask again in case it had been forgotten.

Thanks for checking.

Regards,
Darryl.

16

@dbaker1,

Thanks for asking. I hope everything is now clear at your end.

17

Hi Usman,

I’ve got the boss asking if this will be fixed in your next release? We’ve been promising our customers a new viewer for a very long time (over a year now) but haven’t been able to release it for various reasons - we think that this is the last blocker.

I’m not asking when the next release is coming out, just whether this fix is planned to be in it.

Thanks,
Darryl.

18

@dbaker1,

Thanks for coming back.

Yes, the issue has been fixed and the fix will be part of the upcoming release (v18.10) of GroupDocs.Viewer for .NET.

19

Hi Usman,
We didn’t get any notification that 18.10 was released.

I’ve updated our code and the ModrenUI demo code to use it and can see that the issue has been fixed for the GetDocumentInfo(string guid) overload that the ModrenUI demo uses.

However, our application is using DocumentInfoContainer GetDocumentInfo(Stream fileStream, string fileName, DocumentInfoOptions documentInfoOptions) and this still returns multiple pages.

Can you please look into why this is happening? The fd.xml contains multiple pages as well.

Thanks,
Darryl.

20

@dbaker1,

Thanks for coming back to us.

We really apologize that you didn’t get the notification about the release. The issue was logged as VIEWERNET-1738 and it has been fixed in version 18.10.

Would you please also share with us the properties (along with the values) of DocumentInfoOptions class that you are using in your application? We shall be looking forward to your response.

21

We based our implementation on the ModrenUI demo:

var options = extension != null && extension.ToLower().StartsWith(".xls") ?
new DocumentInfoOptions
{
CellsOptions = new CellsOptions
{
CountRowsPerPage = 150,
OnePagePerSheet = false
}
}
: new DocumentInfoOptions();

In this case we pass a new DocumentInfoOptions();

Thanks,
Darryl.

22

Sorry Usman,

It seems that the nuget update-package didn’t quite do it’s job properly - The debug/Modules window shows I was still loading version version 18.8 of the GroupDocs.Viewer.dll

I’ll fix that and try again.

23

@dbaker1,

Thanks for providing the required details.

We investigated your reported behavior at our end and found that when getting information about your provided .msg file using ViewerImageHandler, GetDocumentInfo gives page count = 5, whereas GetDocumentInfo with ViewerHtmlHandler gives page count =1. The reason behind this behavior is that in image-based rendering it is not appropriate to convert a large document into a single image, therefore, the API breaks down the provided document into 5 pages and renders each as a separate page. However, in the case of HTML based rendering, GetDocumentInfo returns page count =1 and the whole document is converted into a single HTML page.

To avoid any issue, please make sure that you are using the appropriate ViewerHandler when getting document information as well as when rendering the document. For reference, we have created this (109.3 KB) sample application for you that will demonstrate how to use the appropriate ViewerHandler. Hope it helps.

No problem at all. You can try again and share your feedback with us.

24

Thanks Usman,

I have a single helper method that creates the handler, so we are using the same one - it now seems highly likely that I’ve not been using the correct version somehow.

I’ll let you know how I get on out of courtesy - it’s likely to be Monday as it is nearly home time here.

Thanks again,
Darryl.

25

@dbaker1,

Sure, we shall be looking forward to hearing from you.