Better event for the render: download option?

[adaptifyDesigns]

I'm using the render: download option. Some of the pdf documents I'm rendering are quite large, and can take a while to process. So I'm hoping to show a spinner/loading icon while that is happening, but since the "Finished" state fires right after the html is scraped, the loading icon barely has a chance to display at all, and then there is a long pause waiting for the document to render and download.

Has anyone found a way around this? Unfortunately there is no simple method to detect the browsers download event, so I'm not really sure what to do. But I think it definitely represents a major UX flaw, especially for larger documents. The user is left wondering what is happening, and whether it worked or not...

Any ideas?

[kbrown01]

The download as currently implemented is a form post. You could change the code I think. I have done this on an alternate project that calls an XQuery function via GET which in turn calls the core formatter. It uses FileSaver.js functionality to save the returned PDF (https://github.com/eligrey/FileSaver.js/) This code loads a spinner at the start and then removes the spinner after the PDF is retrieved. This code for the other project is like below. You could add a new “download2” option or something, modify the xhr to a POST and post the appropriate data (like the current form POST to the server): function format_article(article, docname) { //enable spinner $('.' + docname).addClass('loader'); var page_width = '210mm'; var page_height = '297mm'; var column_count = '2'; var xhr = new XMLHttpRequest(); xhr.onreadystatechange = function(){ if (this.readyState == 4 && this.status == 200){ saveAs(this.response, docname + '.pdf'); // remove spinner $('.' + docname).removeClass('loader'); }} xhr.open('GET', 'customer-formatter.xq?article=' + article + '&page_width=' + page_width + '&page_height=' + page_height + '&column_count=' + column_count + '&territory=' + user_territory); xhr.responseType = 'blob'; xhr.send(); } Unfortunately I am working on that other project and don’t have time to implement this right now. If you do, please share what you did to integrate into the core. Kevin Brown Xportability From: adaptifyDesigns [mailto:[email protected]] Sent: Friday, February 24, 2017 6:31 PM To: Xportability/css-to-pdf <[email protected]> Cc: Subscribed <[email protected]> Subject: [Xportability/css-to-pdf] Better event for the render: download option? (#58) I'm using the render: download option. Some of the pdf documents I'm rendering are quite large, and can take a while to process. So I'm hoping to show a spinner/loading icon while that is happening, but since the "Finished" state fires right after the html is scraped, the loading icon barely has a chance to display at all, and then there is a long pause waiting for the document to render and download. Has anyone found a way around this? Unfortunately there is no simple method to detect the browsers download event, so I'm not really sure what to do. But I think it definitely represents a major UX flaw, especially for larger documents. The user is left wondering what is happening, and whether it worked or not... Any ideas? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsJo3HWApe31r8zLjttSzsLkkC05o0qks5rf5JIgaJpZM4ML3x2> . <https://github.com/notifications/beacon/AAsJoyTmrRQoqzDHqUa-D9P3CHA6QcGlks5rf5JIgaJpZM4ML3x2.gif>

[adaptifyDesigns]

Thank you so much for the creative idea. It is a little too complex for me, so I've come up with a different solution. I'm using the click event on the Download button to trigger a loading animation, and a hidden element becomes visible and covers the Download button with a message asking the user to wait for the download to complete. The message also instructs the user to "click the x in the upper right corner" in order to use the download button again (clicking the x removes the loading animation). This way the user knows to wait until the PDF is generated, and then they can also reset the Download button and us it again if they want.

So far this is working for most, although I have received a few reports that the feature is not working. One user said that the PDF generated but did not have a file name, and he could not save the file to his computer. He was using an older version of Chrome (49.x.xxx...) on Windows XP.

Another user said that the loading animation just kept going and going, but no file was ever generated or downloaded. I haven't gotten their system details yet.

I chose not to specify the "render" option for my download button options, hoping that this would be the most compatible, allowing each browser to choose the best render mode, but now I'm wondering if there is another configuration that would be more cross browser compatible.

What is the best way to make this work on as many browsers and operating systems as possible?

Thanks!

[kbrown01]

1) Download means just that – download. It will always trigger a download. 2) Not using download means it will default to whatever the browser allows between download and render. Chrome and Firefox would base64 encode and display in a new window. If you do this on Chrome, you cannot save the file. Talk to Google on that one. If you do it on Firefox, you can save the file. If you use a mobile browser or IE or Edge, it will always switch to download as your cannot display base64 encoded PDFs in an <object> tag in those browsers, it is not supported. You can test all these out on http://www.cloudformatter.com/CSS2Pdf.Demos.Structures If you select Open->PDF, this is the default which is render. You can test each browser and see what happens. If you always want “download” then you specify “download” and then download would happen on all as it is supported on all. So Chrome users don’t need to Save after, it will be saved. Firefox, Edge, IE and mobile browsers all work too. For the user that said the animation kept going, I have no idea because according to your writing clicking the “X” should have stopped it. Kevin From: adaptifyDesigns [mailto:[email protected]] Sent: Friday, March 03, 2017 8:20 AM To: Xportability/css-to-pdf <[email protected]> Cc: kbrown01 <[email protected]>; Comment <[email protected]> Subject: Re: [Xportability/css-to-pdf] Better event for the render: download option? (#58) Thank you so much for the creative idea. It is a little too complex for me, so I've come up with a different solution. I'm using the click event on the Download button to trigger a loading animation, and a hidden element becomes visible and covers the Download button with a message asking the user to wait for the download to complete. The message also instructs the user to "click the x in the upper right corner" in order to use the download button again (clicking the x removes the loading animation). This way the user knows to wait until the PDF is generated, and then they can also reset the Download button and us it again if they want. So far this is working for most, although I have received a few reports that the feature is not working. One user said that the PDF generated but did not have a file name, and he could not save the file to his computer. He was using an older version of Chrome (49.x.xxx...) on Windows XP. Another user said that the loading animation just kept going and going, but no file was ever generated or downloaded. I haven't gotten their system details yet. I chose not to specify the "render" option for my download button options, hoping that this would be the most compatible, allowing each browser to choose the best render mode, but now I'm wondering if there is another configuration that would be more cross browser compatible. What is the best way to make this work on as many browsers and operating systems as possible? Thanks! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AAsJo-9iQpVkqVw9jwHw94WODe45oO1wks5riD2rgaJpZM4ML3x2> . <https://github.com/notifications/beacon/AAsJozUmxnSJvhmo-aWE5y0VVf0GabL6ks5riD2rgaJpZM4ML3x2.gif>

[adaptifyDesigns]

Ok, great. Thank you for your response.

The only reason I was confused, is because when I chose not to specify the "render" mode, using chrome on Mac OS the default was an automatic download, without any base64 encoded preview, which is also what happens (for me on Chrome) when I choose the "Open > As PDF" option on your demo pages. So I assumed that the feature was no longer functioning properly.

No matter, I will switch to render: 'download' for best compatibility.

Cheers!