Viewing pfd from web

[gigi]

Hi,
sometimes and only from some browser client (however all Internet Explorer are 6Sp1 + patches) I'm not able to view pdf from web interface. When I select "view pdf" a blank page is displayed. configuration is:
Enterprise server 8.93_E1 - AS400
Web Server with WebSphere 4.05 - Windows2000

thanks in advance
Gigi

 

[dan_richards]

Ensure that each client has a windows file association for .pdf pointing to Adobe Acrobat Reader.

 

[jgvargas]

it remembers that Acrobat Reader requires to be installed in your computer so that also you can visualize archives pdf. the acrobata to reader that I recommend to you is the Acrobat Reader 5 or 6, these versions contain in its bar of tools the option "to save Like", that usually is very util in the Web.

En español:
recuerda que el acrobat reader requiere estar instalado en tu computadora
para que tambien puedas visualizar los archivos pdf, los acrobata reader que te recomiendo es el Acrobat Reader 5 o 6, estas versiones contienen en su barra de herramientas la opcion de "salvar Como", que suele ser muy util en la Web

 

[Soul Glo]

Also make sure that none of these machines are running any sort of pop-up blockers. We have instances here where they can cause this to happen.

 

[shearerj]

We encountered a similar issue today with Adobe. Our current thought is that it is related to HTTP compression. The problem went again after we disabled compression.

 

[winterc]

Adobe can start up individually or as a plugin in IE Exlorer. If you are using the plugin check your security settings including as mentioned the pop-up blocker which looks more than likely the cause. You can also start up Adobe by itself and set off the automatic open with the browser. I you can get the Adobe file after this change then your browser is the problem.

 

[JEMILLER]

Re: Viewing pdf from web

Yep, the HTTP compression seems to cause problems with PDF's. You should not however have to turn it off completely. For some reason the PDF file passes through the web server as a file with ".ube" extension. This needs to be listed in the httpd.conf file.

Here are the details from the KG:

When users submit reports on HTML session, at times, they cannot view the PDF. When they click "view PDF" on the row button it displays a screen "The File is damaged and could not be repaired".
The PDF can be viewed from the workstation.

RESOLUTION:
This symptom is due to PDF compression settings for HTTP 2.0 in the httpd.conf file.

The existing line in the httpd.conf file  will look like this:
SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary

Should be changed to:
SetEnvIfNoCase Request_URI \.(?df|ube)$ no-gzip dont-vary

When the PDF file is downloaded, the compression does not recognize it as a .pdf file, but a .ube file. This has caused some corruption in PDF files while uncompressing on the client. As PDF's are compressed anyway, the benefit of compressing them with HTTP server is next to nothing.

Once these changes are made to the httpd.conf file, restart the HTTP server.

SEARCH TEXT:
IHS, OTP, JAS

System code: H98
Program ID: IBM HTTP Server
Release: 2.0
Service Pack/Tools Release:
Platform: Windows 2000

Regards,

 

[winterc]

Re: Viewing pdf from web

Would this problem exist with hardware compression instead of software compression? In this case HTTP software compression.

 

[JEMILLER]

Re: Viewing pdf from web

I can't speak for a specific hardware compression device but my feeling is that you would have the same problem. The basic issue is that IE is not consistently decompressing the PDF before passing it launching the Adobe browser plugin. The Adobe plugin is not expecting a compressed file. My experiments show that it might be a timing issue. Sometimes I find that a file cannot be opened and pressing refresh in the browser allows the file to be opened. My guess is that on the refresh IE has had time to decompress the file and the plugin loads the decompressed version.

I have worked around this by turning off the plugin. This allows IE to download the file to a local temporary directory before launching the normal copy of Acrobat Reader or Acrobat. This works fine.

This is a problem with not just JDE software. If you hunt around on the web you will find that most HTTP software/hardware based compression solutions experience this same problem. It is an IE browser bug. If the browser did its job this would not be an issue.

Regards,