Adobe Reader X and Page Embedded PDFs

[Guest]

We are experiencing an issue across our corporation wherein, post-upgrade to Adobe Reader X, websites opened with Internet Explorer containing an embedded PDF frame now show a blank box instead of the PDF.  Firefox will display these sites correctly and I have verified Firefox is using the updated Reader X plug-in.  This has been tested across many configurations and behaves consistently in this fashion.  Reversion to Adobe Reader 9 appears to solve the problem, however, this is not a true solution.

Help?

[this_is_niko]

I found the article which can help us to solue the problem

here mentioned something is related to the http header"Cache-Control:

no-store, no-cache"

http://forums.adobe.com/message/3331557#3331557

tomorrow I will try it.

2011/1/14 miss_feminem <forums@adobe.com>

I'm having the same issue. It works fine in Firefox but not in IE6, 7 or 8.

>

I checked the plugins and I'm on version 10 so not really sure what the

problem is here.

>

Has anyone got any updates on this?

>

[Guest]

I noticed that this error seems to also be in IE 9 Beta,  and Only through web sites that are not delivering there PDF's with a direct link. I use Chase.com and verizonwireless.com and both of these site's use a .aspx file to link to statments,these don't load with Adobe Reader X Plugin on win XP 32bit or Win 7 64bit running IE 8 and IE 9 Beta but the do work in Firefox, and Safari using the same Adobe Reader X Installation.

[this_is_niko]

I found the article which can help us to solue the problem

here mentioned something is related to the http header"Cache-Control:

no-store, no-cache"

http://forums.adobe.com/message/3331557#3331557

tomorrow I will try it.

2011/1/16 059lve <forums@adobe.com>

I noticed that this error seems to also be in IE 9 Beta, and Only through

web sites that are not delivering there PDF's with a direct link. I use

Chase.com and verizonwireless.com and both of these site's use a .aspx

file to link to statments,these don't load with Adobe Reader X Plugin on win

XP 32bit or Win 7 64bit running IE 8 and IE 9 Beta but the do work in

Firefox, and Safari using the same Adobe Reader X Installation.

>

[this_is_niko]

if use <iframe>

i think it should be in following way.

<script language="javascript">

window.frames["myfrm"].location.href="my.pdf";

</script>

my pdf now ok in ie6/7/8/9 firefox3.6 chrome9

[Dhampir1]

Try in your php code :

header("Accept-Ranges: bytes");

working for me.

[Guest]

Hi all,

Adobe just release the 10.0.1 version that seems to solve thie issue for us.

[JFlintBean]

I'm glad to report that problem is fixed.

Now, IE works fine opening PDF streams in the browser window.

Thanks, Adobe.

[cobberas]

The problem was still there in my system, using Adobe Reader 10.0.1 and IE8

The solution I used was this: (from FAQ in http://www.fpdf.org/)

3. I try to generate a PDF and IE displays a blank page. What happens?

First of all, check that you send nothing to the browser after the PDF (not even a space or a carriage return). You can put an exit statement just after the call to the Output() method to be sure. If it still doesn't work, it means you're a victim of the "blank page syndrome". IE used in conjunction with the Acrobat plug-in suffers from many bugs. To avoid these problems in a reliable manner, two main techniques exist:

- Disable the plug-in and use Acrobat as a helper application. To do this, launch Acrobat, go to the Edit menu, Preferences, Internet, and uncheck "Display PDF in browser". Then, the next time you load a PDF in IE, it displays the dialog box "Open it" or "Save it to disk". Uncheck the option "Always ask before opening this type of file" and choose Open. From now on, PDF files will open automatically in an external Acrobat window.

The drawback of the method is that you need to alter the client configuration, which you can do in an intranet environment but not for the Internet.

- Use a redirection technique. It consists in generating the PDF in a temporary file on the server and redirect the client to it. For example, at the end of the script, you can put the following:

//Determine a temporary file name in the current directory
$file = basename(tempnam('.', 'tmp'));
rename($file, $file.'.pdf');
$file .= '.pdf';
//Save PDF to file
$pdf->Output($file, 'F');
//Redirect
header('Location: '.$file);

This method turns the dynamic PDF into a static one and avoids all troubles. But you have to do some cleaning in order to delete the temporary files. For example:

function CleanFiles($dir)
{
    //Delete temporary files
    $t = time();
    $h = opendir($dir);
    while($file=readdir($h))
    {
        if(substr($file,0,3)=='tmp' && substr($file,-4)=='.pdf')
        {
            $path = $dir.'/'.$file;
            if($t-filemtime($path)>3600)
                @unlink($path);
        }
    }
    closedir($h);
}

This function deletes all files of the form tmp*.pdf older than an hour in the specified directory. You may call it where you want, for example in the script which generates the PDF.

[loranger_guy]

I know we fixed the issue by pushing a registry edit. if you go to

edit

preferences

internet

uncheck display pdf in browser

or we pushed the reg key

HKCU\Software\Adobe\Adobe Acrobat\10.0\Originals\

in there create a dword value bBrowserIntegration with hex data 0

if i did not make myself to clear this link is pretty much what we did

http://forums.adobe.com/message/3459238

[JFlintBean]

This is not really a fix, just a workaround.

The goal is to show PDF in the browser window, not in the reader window.

I'm going to test our app with IE and Reader 10.0.1 tomorrow.

[mac_portugal]

Hi all,

Same problem.

I have IE 8.0.6001.187702, Windows XP Pro 32 bits.

I tried this update to 10.0.1.

http://www.adobe.com/support/downloads/detail.jsp?ftpID=4969

But doesn't help.

[mac_portugal]

I found some clue.

I have a servlet that foward to another servlet to write the PDF to the response.

If i use redirect instead of forward in the server side, it works.

resp.sendRedirect(req.getContextPath() + "/OutputDocument");

insted of

getServletContext().getRequestDispatcher("/OutputDocument")
                        .forward(req, resp);

[bertrandlefort]

Hi,

We have the same issue with our form here.

Basically, we have forms with a submit button that send a FDF to a server. The server send back a new FDF with more data and a path to a new pdf.
Works for years now and stop working with Acrobat 10.

We realised that:

- installing a copy of Acrobat Reader 10.1 on a new computer (Acrobat never installed) : the submit FAILED;

- upgrading a version of Acrobat > 9 with Acrobat Reader 10.1 : submit OK

- upgrading a version of Acrobat 8 with Acrobat Reader 10.1 : submit Failed

- installing a copy of Acrobat Reader 10.1 on a new computer (Acrobat never installed), uninstall it, install version 9, do update, then upgrade to 10 : submit Ok

This behavior was the same on different Windows OS (XP Pro and 7 Pro).

Firefox and Chrome are out of concerned since the pdf open directly in Acrobat Reader.

Submit the form in Acrobat Reader direcly (not in the browser) works in all scenario.

i am wondering if Adobe introduce a security improvement by design in the Acrobat Installer or if it is a bug. In the first situation, the problem will come back with future releases.

My 2 cents

Bertrand

Message was edited by: bertrandlefort Our files all ends by .pdf, there are not dynamically generated. On the form is a submit button that send the FDF to the server. In the FDF a new PDF location is set for the printable version. For now, we recommend users to save forms on their desktop until we see if the issue will come back in later version.

[bertrandlefort]

I think this is due to a registry issue.

On a VM, I did the following test:

- install 10.1, test : FAILED

- backup registry A

- uninstall 10.1

- install 9 and do update : SUCCESS

- backup registry B

- install 10.1 : SUCCESS

- backup registry C

- restore  backup registry A : FAILED

- restore backup registry C : SUCCESS

I did the last 2 steps twice.

If anyone is interested to see the diff3 files, I will keep them for a couple of days.

Bertrand

[jk0815]

hey bertrand,

we have the same issues with the grey screen while opening a static pdf in a browser (url ending on .pdf) on our windows server 2008 r2 environment.

could you please post the diff's you found?

thank you!

-jk

[bertrandlefort]

Hi,

Here is the link, I zip them:

http-//web5-uottawa-ca/www2/hr/shared/Archive.zip

I hope it could be usefull. The diff are big files. I cannot figure how to use it, but I am not familiar with Windows registry since I work mostly on linux.

- diff-X-9 is the diff of the registry between Version 9 and X.

- diff-X-fresh-with-X-after-9 : compare the fresh installed of X with the version X installed after 9

- diff3 is a diff3 of the 3 registry (X new install, 9 [latest] and X after having installed 9)

I can send you the registry copy if you wish but its big.

Bertrand

[blissfulllife]

(DYNAMIC PDF-Streamed PDF- EMBED PROBLEM SOLUTION...)

Hi, everyone,

I had been experiencing the same problem for a long time..I had been googling, searching in lots of forums. I found the solution...Here it is:

*** The problem occurs -as mentioned in previous messages- when DYNAMIC PDF is the case...Static PDF is always OK...But like me, lots of programmers, in .JSP servlets or whatever
, sends the generated PDF to the client browsers as a STREAM...That is DYNAMIC PDF.

*** The problem is not because of ADOBE READER or sth. It is because of INTERNET EXPLORER....In firefox there is no such problem....As I learned, IE don't look at the concent type
header like "application/pdf" to understand the content....But it definitely looks the URL ending...if it ends with ".PDF" then IE thinks that incoming stream is PDF content then it calls the ABOBE READER plugin...
Then problem disappears....

*** So, the solution is: Change the URL, to end with "http://.......pdf" then it will be OK....

*** In my case, the URL was "http://servername:serverport/contextroot/ViewDoc.jsp&docid=12345"    like this....

I only, programatically, added to end of URL, the fake string :          "&a=a.pdf"

so url became ; http://servername:serverport/contextroot/ViewDoc.jsp&docid=12345&a=a.pdf         ...........that's all....it always works nowwwwwww...

IE now looks at the URL and sees that that ends with ".pdf" and thinks that incoming stream content is PDF then calls ADOBE READER plugin and shows the pdf content in browser...

(I tested this on IE6 and IE7,,,but later versions will be OK,too  I guess..)

(Of course, this solution applies, ony if you are a programmer and you can change the code....In other cases, the solution --as mentioned in previous messages-- is "OPEN the PDF externally, not in browser...by launching the viewer app.like Adobe reader..")

[wolfzombie]

I was having an issue with a red x appearing in IE8 (32-bit) on Windows 7 (64-bit) when trying to view embedded PDFs.  The addon had installed and was showing up in the list of addons for IE8, but the addon would never load, leaving a red x.  I checked the DLLs loaded into the IE process and noticed that only a AcroIEHelper and AcroIEHelperShim files had loaded.  I tested on a working machine and there were a few more Acro dlls loaded.  I assumed the shim was failing to load the correct DLL.  It turned out I was missing a registry key that was pointing to the AcroPDF.dll that is required by the plugin.  To fix it, I added the following to my registry (Window 7 x64):

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CA8A9780-280D-11CF-A24D-444553540000}]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Stats\{CA8A9780-280D-11CF-A24D-444553540000}\iexplore]
"Type"=dword:00000001
"Flags"=dword:00000000
"Count"=dword:00000003
"Time"=hex:db,07,08,00,01,00,0f,00,10,00,0e,00,32,00,05,02

I added the same set of keys in my HKEY_USERS section (same path, but with the user id added between HKEY_USERS and Software).

This fixed the issue on my machine, and it loaded the embedded pdf next time I tried opening one in IE8.

NOTE:

{CA8A9780-280D-11CF-A24D-444553540000} is the Class ID for my installed AcroPDF plugin.  It may be different on your system depending on the version of Reader you have installed.  You should replace it with your Class ID which you can find with the following method:

• Open IE
• Go to "Tools"->"Manage Add-ons"
• Change "Show:" to "Run without permission"
• Right click on "Adobe PDF Reader"
• Click "More Information"
• The information is in Class ID

Hopefully this will help someone.  I know I wasted nearly a day of development time trying to work through this issue.

Message was edited by: wolfzombie

[jk0815]

This was an automated answer to my email notification and should be deleted.

[NotAccordingToPlan]

We've run into this issue also. We have been streaming pdfs to our clients with no issues until somebody got a new laptop with Adobe Reader X. We've used various suggestions to get a partial menu back (don't run in protected mode, don't display in read mode by default). However, no matter what we try we can't get menu options to print or save. All we can do is tell them to right click the pdf to get the print option and to type Shift-Ctrl-S to save. Neither is as convenient as what we had up through version 9.4. Version 10.1 may have helped some people but it hasn't helped us. For now, we are discouraging our clients from upgrading Adobe Reader but that is up to their IT departments. We are really hoping Adobe does something to get the IE plugin to work like it used to. This is making things look bad for both Adobe and us.

[jk0815]

This was an automated answer to my email notification and should be deleted.

[PaulNkui]

Here is the solution I found:

http://itissolved.blogspot.com/2011/03/adobe-x-not-opening-pdf-in-ie-window.html

It worked for me.

summary:

1. Open Adobe Reader X.

2. Press "Ctrl K" (Edit=>Preferences)

3. Select General Category from the left pane

4. Uncheck the "Enable Protected Mode at Startup" checkbox

5. Click on "Internet" in the left pane

6. Uncheck everything in the window EXCEPT "Display PDF in browser"

7. Press "OK"

8. Close Adobe X and try to open the document again.

It may not be necessary to uncheck all of these items but this is what we did and it resolved the issue.

[MiaLoren]

I was experiencing the same issues with adobe X and tried numerous solutions mentioned.  Nothing worked.  Adobe released a new version this week.  Today, I updated adobe to version 10.1.2.45.  This fixed my problem.  I am now able to view pdfs in the browser without receiving the blank gray background.

[J_Perkinson]

I am yet another person with the same issues with gray screens until refreshed with streamed PDFs.  On Windows 7 32 bit with ie9 and Adobe plugin version 10.1.2.45 (Adobe reader itself shows 10.1.2).  Having them open directly in Adobe does work, it just gets the gray screen in IE until they refresh (F5).  I have tried the fixes above except for the registry (as they don't seem to apply) and uninstall/reinstall (as these are fresh installations) fixes with no luck.  These are new builds with fresh Adobe X installations.  The pdfs are generated with http: and extensions of .pdf.

[Guest]

We are a large organisation now faced with what appears to be yet another Adobe Reader X issue. With 10.0.0 and 10.0.1, all was fine. With the release of 10.1.0 and 10.1.1 our Adobe interactive forms would load extremely slowly and be impossible to navigate, or lose all data when users tried to submit them online. For example, a business process that should take 1 minute was taking end users 45 minutes to complete. Needless to say, our end users were extremely unimpressed.

When 10.1.2 came out after a 3 month wait, those performance issues appeared to be resolved when we tested it, and our credibility seemed to be on the mend, but that appears to be short lived and premature. Now, the forms don't even load at all on some end user systems, with a grey screen, a blue bar and a message similar to 174kb/0kb loading. It never completes loading and stays stuck on 0kb, and the Adobe Interactive Form does not appear. F5 refresh does not work, and working on the PDF offline as a saved file is not an option. Like J.Perkinson, I have tried all the suggestions except for the registry, as the PC's belong to end users in the public domain. We are limited to what we can advise our end users because they have such disparate systems (XP, Vista, 7), browsers (IE7, IE8, IE9), Adobe Reader( 8, 9 10/X) and we are fast approaching a situation where each Adobe Reader version has particular quirks and settings that just confuses the end user and further undermines our credibility.

Whilst reverting to Adobe Reader 9.4 or 10.0.0 or 10.0.1 will solve their problem in our case, the end users are reluctant to roll back their Adobe Reader installations for security reasons. We don't want to be responsible for causing a security breach and ending up facing legal action. A high percentage of our end users are in the legal profession, so we definitely don't want to go there 🙂

Our PDF's generated with https:and extensions of PDF.

Frustratingly, some users of IE7 and AR 10.1.2 are not having issues, yet others are. It is a similar story on IE8 and AR 10.1.2. Some have fresh installs of AR 10.1.2, whilst others have been progressively been upgrading since 9.x. I am at a loss as to what to do other than hope that Adobe takes notice and action on this forum.