Text file page size doesn't match content

GroupDocs.Viewer Product Family
1

Hi Support,

I’ve based our viewer front-end on the ModrenUI example from GitHub - groupdocs-viewer/GroupDocs.Viewer-for-.NET-MVC-App: Outdated.

I’ve made changes in our implementation to do things that your old installable viewer knockout.JS implementation did - such as load pages as the user scrolls to them, rotate pages, zoom in/out/fit to width and height and display the md-card elements using the page size returned from ViewerHtmlHandler.GetDocumentInfo().

One thing I found was that the page sizes returned in the DocumentInfoContainer are in pixels (as stored in fd.xml), but all of the HTML is in em units - so I had to deduce what 1em was in pixels inside your ViewerHtmlHandler.GetPages().

This works fine for emails, attachments, PDFs and Word documents - but not for text files.

This can be demonstrated with the Modren UI example code.

  1. Clear the AppData\cache folder.
  2. Extract test2.txt from the attached zip file Test2.zip to the AppData folder.
  3. Run the Modren UI example and choose Test2.txt.
  4. Examine App_Data\cache\Test2_txt\html\fd.xml to get the page size in pixels - 612 x 792 - which equates to US Letter size at 72DPI.
  5. Using the browser developer tools, set the width and height of the md-card element to 612 x 792 pixels.
  6. See that the text is offet to the right and off the side of the page.

The reason for this when examining the HTML in App_Data\cache\Test2_txt\html\page1.html seems to be that the page size is used for the parent div - in this case

but the units are in pt rather than em that are used when other file types are rendered.

Please can you advise how I can either get 612pt to be 612 pixels in all browsers, or how to force text file elements to be sized in em the same as other file types?

Thanks,
Darryl

2

@dbaker1,

Thanks for using GroupDocs.Viewer and sharing your concerns with us. We shall investigate your scenario at our end and share the outcomes with you.

3

@dbaker1,

We investigated your scenario at our end and following are the outcomes.

The page size (height and width) in fd.xml are in pt unit that is used to set the size of the parent div in the HTML page. Following are the screenshots of the .txt and .docx file that shows the page size when opening the rendered HTML pages in the browser.

Instead of setting the width and height in pixels, please try to set them in pt unit and the output will be absolutely fine as shown in the following screenshots.

We recommend you to try setting the height and width of md-card element in pt unit. You can set it in index.cshtml as shown below.

<md-card ng-repeat="item in docInfo.pages"  style="width:{{item.width}}pt; height:{{item.height}}pt;">
     <a name="page-view-{{ item.number }}"></a>
     <iframe iframe-set-dimensions-onload align="middle" ng-src="{{ createPageUrl(selectedFile, item.number) }}" allowTransparency="true"></iframe>
</md-card>

Hope it helps.

4

Thanks Usman,

That sort of worked - but I still needed to calculate the display size in pixels because I implemented the fit to width and height functionality from the old installable viewer and the browser has the values in pixels. The error here is that the GroupDocs DLL has assumed a page size in pixels is the same in points. It would be better if all of the HTML was generated with the same units - e.g. the HTML it generates for pdf and docx file have their dimensions specified in em.

I’ve corrected the values as a special case for text files as a workaround by dividing by 72 and multiplying by 96 (W3Schools says 1px = 1/96th of 1in and 1pt = 1/72 of 1in).

Thanks again.

5

@dbaker1,

Thanks for your response.

We can see that the dimensions for the HTML representation of .docx file are in pt unit. However, the HTML generated for PDF document uses em unit. We have logged it in our Issue Tracking System (ID: VIEWERNET-1610) to check if it is feasible to provide HTML representation of PDF in pt unit as well. We shall keep you informed in case of any updates.

6

@dbaker1
We have just released new improved GroupDocs.Viewer UI document viewer application, that may be useful for you.

Kind regards!

7

@dbaker1,

We have got an update regarding your requested feature, logged as VIEWERNET-1610. Currently, it is not possible to provide one unit (either pt or em) for HTML representation of all the supported file formats. If you are interested only in MS Word and PDF documents then we can provide the solution for rendering MS Word documents in the em unit as well, however, there are some shortcomings of using em unit in MS Edge and IE browsers (see screenshot 1, screenshot 2). Please confirm if the output is fine for you when it is viewed in MS Edge and IE.