I know this seems an odd issue, but here goes. We use Aspose.Words to create documents on the fly, and then they are converted to PDF to return to the browser. On version 17.9, if a multi-page PDF is opened and then scrolled to the bottom of the document, then the document is closed, and another document is opened, the new document opens also scrolled to the bottom of the document.
I have verified that changing nothing but switching back to version 16.8 (our older licensed version) this problem goes away.
It was reproduced in both IE 11 and the current version of Firefox.
Thoughts?
@srjbireley,
Thanks for your inquiry. Please attach the following resources here for testing:
- Your input Word document (if any)
- Your expected document showing the desired output. Create it with old version of Aspose.Words
- Aspose.Words 18.3 generated output document showing the undesired behavior
- Please create a standalone console application (source code without compilation errors) that helps us reproduce your problem on our end and attach it here for testing.
As soon as you get these pieces of information ready, we will start investigation into your issue and provide you more information. Thanks for your cooperation.
I have versions 17.9 and 16.8. Version 16.8 does not manifest the problem, but version 17.9 does, and it has to do with the PDF conversion process when saved as a PDF.
I’m including 2 Flash videos to demonstrate the issue since it would take quite a while to make a test project because you’d need a web site.
Basically, our product creates a modified Word document on the fly and then loads the document into a tab in a browser to view.
Steps to repeat:
- Convert a multi-page Word document to PDF and load that PDF in a frame in a webpage. Scroll down to the bottom of the page.
- Close the document.
- Open a new Word document, convert it to PDF, and load it into the SAME frame in the webpage. Note that the new pdf is displaying scrolled to near the bottom of the page.
Only version 17.9 displays this behavior - 16.9 doesn’t. I personally tried just switching back and forth between the versions to verify this, and with no code changes at all (other than updating project references) it works correctly in 16.8, but does the bad scrolling issue in 17.9
If you want to point me to a trial version of the new version, I can try it in our environment.
Thanks!
@srjbireley,
I am afraid, we do not see any videos in this thread. Please ZIP the videos, upload the ZIP file to Dropbox and share the Download link here for our reference.
Sure, please try the latest version of Aspose.Words for .NET i.e. 18.4 and see how it goes on your end. Hope, this helps.
Please also share the resources mentioned in my previous post here for testing. Thanks for your cooperation/
Hi - I thought the 18.4 version had solved this, but I was wrong - the problem just has a slightly different way of presenting. Behind the scenes we use Aspose.Words to dynamically create the document, and then it is saved to PDF, also by Aspose.Words. It’s as if there is some flag in the PDF that tells it to display the first page is being left out. The only difference between the software in these two videos is the version of Aspose.Words.
The issue is illustrated by these screencasts:
18.4 with problem - https://www.screencast.com/t/UNdAjvav
16.8 without problem - https://www.screencast.com/t/OBJKY6cQ
We’re in the purchasing process for escalated support, so I will elevate this as soon as it comes through.
Thanks!
Jeff Bireley
@srjbireley,
Thanks for sharing the videos. I understand what the problem is. May be you can use the following HTML to always display the PDF in iframe at Page 1:
<iframe src="awjava-18.4.pdf#page=1" width="100%" height="800">
Or, this browser does not support PDFs.
</iframe>
Please also provide us a simplified application that helps us to reproduce your problem on our end. We will then be in a better position to address your concerns and provide you workaround.
I tried this, but it didn’t work. Interestingly enough, though, If the first document opened has 4 pages, and I scroll to the very bottom of the document, and then open a document with 5 pages, the document will open at the top of the 4th page. In the image snippet, you’ll see that the first parameter in the URL is #page=1.
The challenge is that to give you an application to duplicate this would require creating a website on your end, since that’s what’s being used. Since that’s not practical, if I were trying to fix this, I’d look at the PDF export process, and how it’s encoding the page numbers in 16.8 versus 18.4. I also tried creating a PDFSaveOptions object and using that, but none of them caused the document to load at the top of the form.
I’m sure there have been lots of changes between 16.8 (where this works) and 17.9 and higher (where it doesn’t), but I’d start with the PDF save stuff - it’s pretty much got to be there.
AsposeWordsPDFPagingIssue.PNG (7.8 KB)
@srjbireley,
We are checking this scenario further on our end and will get back to you soon.
@srjbireley,
I am afraid, this does not seem to be related to PDF document’s layout, neither to Aspose.Words generated PDF itself. It must be something related to script running in the browser or the way how PDF files are delivered to the browser.
We also noticed that you are running scenarios differently in both videos
i.e in 16.9 video you select patient from list before viewing PDF document whereas in other 18.4 version video you leave the patient as blank. It is quite possible that PDF viewer object does not get its view (or scroll position) refreshed when you leave patient as blank and restore its cached view in the browser.
Moreover, our sister company GroupDocs.com offers viewer apps which you may consider including in your application to view the various file formats (including PDF format). For more information, we suggest you please contact GroupDocs support through support forums of GroupDocs.
I must respectfully disagree. While I didn’t create the videos I sent, I have personally duplicated the problem when doing exactly the same workflow with the same patient on the same set of two documents. The only difference was using version 16.8 versus 17.9 or 18.4.
I agree with you that at first glance, I thought it was a browser (or javascript code) issue. I literally took all of that out of the equation and still had the differing results.
I am going to go back and see if I can’t figure out a way to more easily demonstrate the issue, and will let you know what I find out.
Thanks!
Jeff Bireley
@srjbireley,
We will wait for your further input on this.
Please try to provide us a simplified application that helps us to reproduce your problem on our end. We will then be in a better position to address your concerns and provide you workaround.
Okay, believe it or not I have a easy test for the issue. All you have to do is put the attached folder on a web server and bring up the page called displayPDF.html.
- Click the ‘Load 16.9 PDF A’ button - File loads and displays top of document.
- Scroll down to the bottom of the PDF.
- Click the ‘Load 16.9 PDF B’ Button - Note that the PDF is displayed at the top of the PDF.
- Click the ‘Load 18.4 PDF A’ button - File loads and displays top of document.
- Scroll down to the bottom of the PDF.
- Click the ‘Load 18.4 PDF B’ button - Note that the PDF does not display at the top of the page, but at the same relative position as the previous document.
Note that the A and B files for both versions are just two copies of the same document. The only difference is the version of Aspose that created them.
PDFTest.zip (329.3 KB)
Let me know if you have any trouble with the example.
@srjbireley,
We are checking this scenario further on our end and will get back to you soon.
@srjbireley,
Your findings are correct only when testing over Internet Explorer 11 browser on our end.
I am afraid, when switching “Load 16.9 PDF A” to “Load 16.9 PDF B”, the 64-bit Firefox version 60.0 browser does not display the “Load 16.9 PDF B” at the top on our end. It displays the PDF at the top when switching from “Load 16.9 PDF B” to “Load 18.4 PDF A” or “Load 18.4 PDF B”. But again switching between “Load 18.4 PDF A” and “Load 18.4 PDF B” preserves the current scroll position. Maybe because the Firefox browser thinks that both PDFs are same and caches their content and scroll position.
On the other hand, the latest version of Google Chrome browser [Version 66.0.3359.139 (Official Build) (64-bit)] always displays all the PDFs at the top of the page.
Behavior of Microsoft Edge is similar to Chrome in this case.
So, this seems to be a web browser specific issue. If we can help you with anything else, please feel free to ask.
The fact that you can reproduce my results in Internet Explorer absolutely confirms that there is a difference between the PDF’s produced by the two versions of Aspose are the cause the of the problem. Since IE is still the most used browser, we need to have this fixed. We have now obtained the elevated support contract, and I am going to submit this issue through that channel as well.
Thanks!
Jeff Bireley
@srjbireley,
We are checking this scenario further on our end and will get back to you soon.
@srjbireley,
We have logged an investigation ticket in our issue tracking system; the ID of this issue is WORDSNET-16883. Your thread has also been linked to this issue and you will be notified as soon as it is resolved or any updates are available. Sorry for the inconvenience.
@srjbireley,
Regarding WORDSNET-16883, please check below the further analysis details:
The differences you are observing between Aspose.Words versions are related to how Aspose.Words writes the PDF File Identifier. Before 16.11 version Aspose.Words did not write File Identifier for PDF 1.5 compliance, only for PDF/A. Starting from 16.11 version Aspose.Words writes File Identifier for PDF 1.5 compliance too. File identifier is generated based on DocumentInfo. Thus when the same document is saved to PDF twice (or two documents with the same DocumentInfo), the output PDF files will have the same File Identifier. Starting from 18.5 version Aspose.Words generates unique File Identifier. Thus saving even the same document to PDF twice will produce different File Identifiers.
In Internet Explorer 11 PDF files are opened with some sort of Acrobat Reader plug-in. This plug-in seems to save the view settings of the PDF files based on the File Identifier. For the PDF files without identifier it does not save the view settings at all.
So upgrading to latest version of Aspose.Words i.e. 18.5 should help you. Please let us know if upgrading to 18.5 resolves the problem on your end?
In Internet Explorer 11 different PDF files generated by Aspose.Words from the same document will not save the view settings anymore. However opening the same PDF document twice will save the view settings anyway unlike the Aspose.Words 16.9 output without the File Identifier.
P.S. In standalone Acrobat Reader application this behavior is controlled by “Preferences->Documents->Restore last view settings when reopening documents” flag. Maybe there is some way to tune the Internet Explorer 11 plug-in either.