Internet Explorer Developer Center >
Internet Explorer Development Forums
>
Internet Explorer Web Development
>
Erratic Behavior with PDF named destinations.
Erratic Behavior with PDF named destinations.
- Summary
When using IE to link to named destinations from local intranet web services, failure to position properly.
Same test using external webserver, IE works just fine.
Discussion
Adobe PDF files have a feature called Named Destinations.
These are like bookmarks, but can be put anywhere in a pdf page in a document.
They are useful because you can hyperlink directly to a PDF Named Destination in a PDF document, just like with HTML named anchor in an HTML document.
I set up an HTML page that used TARGET= to position the named destination in an IFRAME on the same page.
The problem was that while the positioning worked fine in Firefox and Chrome, with IE8, I would get variable results. Sometimes the named destination would come up fine...other times it would be a page and half off. Sometimes two pages off. Sometimes it would go to the completely wrong named destination...
This all happened when the html code and pdf were on a web server in our intranet. It also happened when all the files were on a local directory.
Then, I put HTML and pdf file on an externally accessible web server...and suddenly it worked just great! One thing I noticed is that the named destination page would come up immediately in the IFRAME, but the whole PDF document would continue to download in the background for a few seconds.
What causes problem?
I'm wondering if there isn't some rendering issue that doesn't show when there is some latency involved, but which is exposed when the file transfers faster because of being on an intranet (?) Any thoughts?
John Bailo
All Replies
- You need to ask on Adobe's forums why the named destination does not always work for IE. Other forum users do not usually have access to Adobe's source code, so they can not fix Adobe's problem for you.
Please mark the post answered your question as the answer, and click the chartreuse pyramid floating over "Vote as helpful" to mark other helpful posts as helpful. This posting is provided "AS IS" with no warranties, and confers no rights.
Visual C++ MVP The problem does not occur with Firefox or Chrome. I believe that IE, Firefox and Chrome all use the same plugin. Therefore, it must be a Microsoft problem.
John Bailo- The browsers you mentioned do not support PDF out of box and rely on browser-specific extensions written by third party to support the PDF rendering in the browser window. Say I wrote an IE extension that support PDF named destination half of the time, that does not mean Microsoft know how my code works or can legally release a bug fix of my software.
Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
Visual C++ MVP
Fair enough...I have a thread open at Adobe Support forums on the issue:
http://forums.adobe.com/message/2138551
John Bailo- This problem appears to be localized to workstations running on our user network.
I tested it from home and from machines running outside our user network (using the browser of one of our external web servers) and IE behaved flawlessly.
I'm considering virus scanners but also possible network hardware problems (routers, hubs) might be at fault.
Still, this problem does not appear with Chrome or Firefox may be either:
(1) Able to work around the network problem due to a different design.
(2) Not tied into our virus detection, content filters and so on.
John Bailo - New information.
We've been testing this across several networks and machines...laptops, desktops.
There doesn't seem to be any guarantee that named destinations will always work with IE8 100 percent of the time.
While the problems are less, using say a laptop on wifi at Starbucks (a test we did on Friday), we still saw a problem with IE hitting the named destination exactly.
So the best I can say for it at this point, is there still appears to be an issue with IE8 and named destinations which is exacerbated by network latency. We see it more on slow networks, less on speedy networks.
My best guess based on that evidence is there is a rendering problem for IE in its DOM.
In our test page, we use several hyperlinks whose target is an IFRAME.
On load, I also see a case where the hyperlinks open the PDFs in a new window...because the IFRAME fails to render before the hyperlinks can be clicked (!)
Overall, my impression is that while IE8 may appear to run fine, when under "stress" of slow loading networks, or dense documents such as pdf, problems can be exposed.
John Bailo - It is not like IE downloaded the file to its cache folder and you click "open" from the file download window. For an ActiveX Document Server like a PDF viewer or Microsoft Office to work it needs to takes over the navigation request and download the file in its own code. Post back to Adobe's forum so they can have more information to resolve this issue.
Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
Visual C++ MVP This all happened when the html code and pdf were on a web server in our intranet. It also happened when all the files were on a local directory.
Hi,
Then, I put HTML and pdf file on an externally accessible web server...and suddenly it worked just great!
Linking the HTML page with the PDF named destination (<a href="http://www.server.com/mydoc.pdf#my_dest"> works only when HTML document is served by a web server. It will not works from a local drive at all.
As I understand, when the html page and pdf file are located on the external web server (rather than local intranet) it ALWAYS works fine in IE. How do you connect to a intranet Web server (by host, IP or FQDN)?
1. If you are using proxy accessing your external website, try to connect the intranet webserver through an assigned proxy as well (then, they should behave in the same way). If it works, you can use Fully Qualified Domain Name on the local intranet (http://webserver.domainname.com/mydoc.pdf#my_dest).
2. Try to configure the cache settings in IE to use the "Every visit to the page" option. Are there any differences?
As I understand, when the html page and pdf file are located on the external web server (rather than local intranet) it ALWAYS works fine in IE. How do you connect to a intranet Web server (by host, IP or FQDN)?
Subsequent testing with external pages showed that even when accessing the web server externally (and we tried it from several home PCs, even a laptop using Wifi at Starbucks), IE always performed erratically when using named destinations, whereas Firefox and Chrome always performed flawlessly.
Further research indicated that the complaints about the behavior of IE and Named Destinations go back as far as Internet Explorer 4 !!
John Bailo- Yes, IE 's documentation about ActiveX document interfaces is not that many. The situation hasn't changed since IE4. No wonder even companies as big as Adobe can not make their IE plugins perfect.However this is a problem between Adobe and Microsoft. Forum users like me do not have access to the source code in Adobe or in Microsoft, so they cannot know what's the misunderstanding between them.
The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful.
Visual C++ MVP - Yes, absolutely.
Since FF and Chrome are open source, I can examine how they implement the Adobe plugin.
Yet, since IE is closed, I can do nothing about it.
This type of problem really makes the case for open source -- especially with a product like IE which Microsoft does not sell for money.
As it is -- since neither MS nor Adobe admit to the problem, I as a developer cannot use named destinations in my deliverable!
John Bailo
