Is there a way of writing PDF byte data to an IFrame clientside

Question

Odd question I know but say one has PDF byte data contained within a hidden field on a page which also has an IFrame on it.

Is there a way of writing the pdf data to the IFrame using JavaScript such that the IFrame will load in the adobe plug-in and display the data?

The reason we'd like to do this is that we need the PDF data in the hidden field anyway so if the user clicks a button we can call a Java applet via JS with the data so it writes the PDF byte data to a proprietary system. We'd also like to display the PDF as well.

So:

1. PDF byte data (generated on the server) chucked in the hidden field.
2. PDF byte data from hidden field written clientside to IFrame by some soon-to-be-discovered-via-the-wonders-of-StackOverflow JS magic and thus displayed.
3. When button clicked Java applet called clientside passing in PDF byte data stored in hidden field

Just like Southpark's underpant gnomes we've got phase 1 and 3 but not 2!

Any ideas gratefully received!

Further info:

We need to have the byte data available on the client side to be passed via a JS call to a Java applet. We do this currently via a hidden field. That's okay and it works just fine.

The problem is that the call to the applet only takes place if the okay button on an ajax modal dilaog is clicked ('Do you want to send this document to UglyProprietorySystem?').

As you all know you can't put anything on top of an adobe plug-in display. Obviously if the whole page is of type PDF then there's no place for any JS to show the dialog so that wouldn't work and if you use an IFrame you still can't put anything on top of what the plug-in displays (it's effectively another app's airspace and violating that is just plain rude!).

We worked around this by:

1. Inititally showing a blurred image of a generic PDF doc and popping the modal dialog on top of that.
2. When the user had responded to the dialog we called (or not) the java app with the pdf byte data from the hiden field
3. We then posted back after clearing the hidden field (Woo! Posting back a form with PDF binary data is not appreciated by the server!)
4. In the page_load of the code behind we then, on postback, wrote to the response stream with he PDF byte data, setting the contentype to be appplication/pdf and thus the pdf is displayed.

Lovely. It all works and gets us kind of what we'd like.

Only problem is we either need to:

* generate the PDF data twice (once on initital page_load for the clientside call to our applet and then again on postback to display).

or

* We store the PDF byte data in the session after the first response so as to be able to, after the postback, still have the pdf data to be able to display it.

Neither is great but we went with the latter but now we're thinking we'd like to avoid that if we can.

Thus the idea of generating the PDF, putting it into a hidden field, having a button on the page to save the PDF to our proprietary system via an applet call and also writing to the IFrame with that data already on the client in the hidden field thus displaying it.

Phew!

So that's why we wanted to on the client using JS, write the pdf binary data to the IFrame and have it's content type set to application/pdf so the browser would load up the adobe plug-in and display it.

Answer 1

Nope there is no interface that would allow you to this sort of thing in the web-side security sandbox. The reason you aren't just downloading the PDF from the server is?...

Answer 2

As I said in my question we already generate the PDF data on the server.

We need to have the byte data available on the client side to be passed via a JS call to a Java applet. We do this currently via a hidden field. That's okay and it works just fine.

The problem is that the call to the applet only takes place if the okay button on an ajax modal dilaog is clicked ('Do you want to send this document to UglyProprietorySystem?').

As you all know you can't put anything on top of an adobe plug-in display. Obviously if the whole page is of type PDF then there's no place for any JS to show the dialog so that wouldn't work and if you use an IFrame you still can't put anything on top of what the plug-in displays (it's effectively another app's airspace and violating that is just plain rude!).

We worked around this by:

1. Inititally showing a blurred image of a generic PDF doc and popping the modal dialog on top of that.
2. When the user had responded to the dialog we called (or not) the java app with the pdf byte data from the hiden field
3. We then posted back after clearing the hidden field (Woo! Posting back a form with PDF binary data is not appreciated by the server!)
4. In the page_load of the code behind we then, on postback, wrote to the response stream with he PDF byte data, setting the contentype to be appplication/pdf and thus the pdf is displayed.

Lovely. It all works and gets us kind of what we'd like.

Only problem is we either need to:

• generate the PDF data twice (once on initital page_load for the clientside call to our applet and then again on postback to display).

or

• We store the PDF byte data in the session after the first response so as to be able to, after the postback, still have the pdf data to be able to display it.

Neither is great but we went with the latter but now we're thinking we'd like to avoid that if we can.

Thus the idea of generating the PDF, putting it into a hidden field, having a button on the page to save the PDF to our proprietary system via an applet call and also writing to the IFrame with that data already on the client in the hidden field thus displaying it.

Phew!

So that's why we wanted to on the client using JS, write the pdf binary data to the IFrame and have it's content type set to application/pdf so the browser would load up the adobe plug-in and display it.

Answer 3

I can't seem to locate any of the sites I investigated this on recently, but there is a feature supported by MOST browsers (including IE8 and limited in earlier IE versions) where you can specify a data: uri in the src field of an iframe (and often other tags as well). Basically, the uri is along the lines of src='data:application/pdf;Base64,;'

It will probably take some fudging of formats to make it cross-browser compatible but it should give you a place to start.

Answer 4

Why couldn't you create a callback function on the client to check for the presence of the final file on a periodic basis via a post or get? Point the browser to the "thumbnail" image then fire off a post/get to the final file, swallow the error until the file is ready. Once the file is available the client will simply download it.

Answer 5

Use an "object" element and put your PDF data in the "data" parameter.

Not sure about creating PDF in JS, but I know it's possible, just not easily available in a library.

See http://support.microsoft.com/kb/201515 . The MS KB article shows this example:

<OBJECT ID="myCtrl" WIDTH=50 HEIGHT=50
 CLASSID="CLSID:nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn"
 DATA="DATA:application/x-oleobject;BASE64,j43aWGqdGxCvwEIQECqNpy
           FDNBIIAAAA7QMAAO0DAACAfuHmAgAFADEAAAAQ">
</OBJECT>

I'd look into browser support before doing this. Now that IE8 is a forced update, there should be better support, but I can't speak from experience on IE nor FF or Safari etc.