Linking to external PDF from CHM fails on Windows 7 64bit

[Thomas Grehl]

Hi!

I have been using the method described about a year agou by Tim in

http://helpman.it-authoring.com/viewtop ... f=2&t=9987

to link to external PDF files with relative path. This has worked very nicely until recently. I am not sure if this was one of the more recent windows updates breaking it, the new version of Adobe Reader, or something else, but currently the links fail under Windows 7 64bit, while they still work on the 32bit version at the same patch level, Adobe Reader version etc.. When failing, a "broken image" symbol is displayed instead of the PDF viewer embedded in the CHM browser.

Any clues? Any other method of linking to external PDFs, e. g. some way of having them just "executed" so they are opened in a separate window/context with the defauls PDF viewer?

thanks in advance for your comments,
Thomas

[Tim Green]

Hi Thomas,

Are you using the latest update of Adobe Reader? There was a similar problem with Adobe Flash, in which it would only work when linking to it on 32-bit versions of Windows, but Adobe eventually fixed it and it now works on both versions.

[Thomas Grehl]

Hi Tim,

yes, latest Adobe Reader 11.0.3. I went back to 10.1.4 and 9.5.0 (which both used to work) and still no success.

More observation:the "file://" link in the help topic works when copied to a browser or run from the command prompt. When I save the CHM topic that contains the <empbed> tag as HTML file and open it with Firefox it works. Opened with Internet Explorer 10 works only after confirming a security message, but this is the same with 32bit and 64bit. However, after downgrade to Internet Explorer 9, there is a choice between 32bit and 64 bit IE in the start menu. When chosing 32bit on a 64bit Windows 7, the same HTML file displays correctly. When chosing 64bit IE, it comes with the same security question, but does _not_ display the PDF afterwards.
Suspicion: From IE 10, the 64bit version is always used on 64 bit operating system, and then fails to display the embedded PDF viewer. Increased security restrictions?

Any ideas to get around this?

best regards,
Thomas

[Tim Green]

Hi Thomas,

Your investigations confirm what I suspected: This is a conflict between 32 and 64 bit programs on a 64-bit system. On 64-bit Windows you need to be able to run 32-bit programs, because there are lots of them. This is less of a trivial issue than you might think. Windows handles it by having what you can think of as a "context" for every program, which is either 32-bit or 64-bit. When Adobe Flash was only 32-bit compatible, Flash movies would play fine on the 32-bit version of Internet Explorer, but not on the 64-bit version, because a link to a Flash movie from the 64-bit version would be executed in the 64-bit context, where 32-bit Flash would not run.

This is why you would sometimes get the seemingly odd effect that a link to a Flash movie in a CHM would run fine when the CHM was opened automatically by Help & Manual after publishing, but would fail if you double-clicked on the CHM in Windows Explorer, or started it from a 64-bit application that you programmed: Help & Manual is a 32-bit program, so it is always operating in the 32-bit context. When it opens a CHM, it opens it in a 32-bit context, which means that it uses the 32-bit version of Internet Explorer to render the HTML, and that in turn calls Adobe Flash Player in the 32-bit context, which works fine. When you double-click on a CHM in Windows Explorer, on the other hand, it opens in the 64-bit context, because Windows Explorer is 64 bit. Called from there, the older version of Flash Player failed, because it could not work in 64-bit.

In turn, this is why nothing can be done about this: The link is correct, but for whatever reason Adobe Reader can't open the file in the current 64/32 bit context configuration. The only solution for Adobe Reader would be for Adobe to correct their configuration, which will probably happen eventually. In the short term, you can almost certainly solve it much more efficiently by installing any other free PDF reader as your default program for opening PDF files. Adobe Reader has turned into a bloated monster and you really don't need it most of the time. For most purposes, free programs like Foxit, Sumatra, Nitro or PDF-XChange will be faster and more efficient.

[Thomas Grehl]

Hi Tim,

thanks for the explanation, and I agree that Adobe Reader is a mess - but we will have to live with the fact that our customers use it. Anyway, when using Foxit as the default PDF application and uninstalling Adobe Reader. As soon as Adobe Reader installed again, it is also used, although Foxit is the defaul handler for PDF both in Internet Explorer as well as the normal Windows context.

Let's hope Adobe has a fix soon, thanks for the nice support,
Thomas

[Kris Habraken]

I too encountered this problem, and have found a solution for it.
Add the following attribute to your PDF hyperlinks in the html: target="_blank"

This attribute is used on webpages to instruct the browser to open a new window/tab to display the link in, rather than loading it in the current window/tab. In the HtmlHelp viewer, this causes the external PDF viewer (Adobe Reader) to start, and open the PDF file specified in the link. This enables you to get around not being able to view PDFs in-frame in the HtmlHelp viewer on 64bit systems (as described by Tim Green).

Example:

Code: Select all

Before:
<a href="/path/to/document.pdf">Click here to view PDF document</a>
After:
<a href="/path/to/document.pdf" target="_blank">Click here to view PDF document</a>

(You could use javascript to automatically add this attribute to all links ending in .pdf when the page loads, if you have a lot of pdf links to fix)

[Tim Green]

Hi Kris,

Thanks for posting this. Rather than doing this per JS, which would add an unnecessary overhead every time a page is loaded, it would be better to update it in your project. When creating links you just need to use an Internet link instead of a file link, and make sure that the Target Window: option is set to "new window". Then the target will automatically be "_blank". If you have a lot of them you can use Help & Manual Toolbox to search and replace in the source code in your project to replace the links.

A file link looks like this in the XML source:

Code: Select all

<para styleclass="Normal"><link displaytype="text" defaultstyle="true" type="filelink" href="testfile.pdf" styleclass="Normal" translate="true">PDF Link File Link</link></para>

And you need to change it to look like this:

Code: Select all

<para styleclass="Normal"><link displaytype="text" defaultstyle="true" type="weblink" href="testfile.pdf" target="_blank" styleclass="Normal" translate="true">PDF Link Net Link</link></para>

The attached .hmsearch file is a search profile for doing this for HM Toolbox. It will convert file links pointing to PDF files to web links pointing to PDF files, keeping the file names, captions and styles in the links the same. Make a backup of your project first, then just load your project in HM Toolbox, select the Complex Find and Replace option in the Tools menu and then load the attached .hmsearch profile. You can perform a preview first before you actually execute the operation, to make sure it is working OK.

[Kris Habraken]

Thanks Tim. I'm not familiar with the HM software (we use our own toolchain), but found this thread via a message on the Adobe Robohelp forum (describing the same issue) when I was investigating, so thought I would cross post the solution here.

[Thomas Grehl]

Tim, Kris,

thanks for finding this solution and the easy implementation. I will have look and consider this fixed. As always, the forum is excellent!

Thomas

[Thomas Grehl]

Dear Tim,

I added "internet links" with relative path to the external PDF files we would like to refer to (total: 100 MB, sepearate installer). This seems to work fine for most users, but unfortunately the compiled CHM has grown in size by about the cumulative size of all linked PDFs!
At compile time, the PDFs are in the same folder as the *.hmxp, ar runtime they should be one level higher. The links work even with the PDFs not present on the target computer, which proves they are integrated into the CHM.
When I remove the PDFs at compile time, the file size is very small, but the links don not work on the target computer even when the PDFs are present at the right path or in the same folder as the CHM.
So the idea using internet links is not really a solution. Further ideas? We are using 6.4.1 build 2923

thanks,
Thomas

[Tim Green]

Hi Thomas,

The PDF files should only get embedded in the CHM if they are stored in your Baggage Files section. Please check to make sure whether they are there. On links to external files from CHMs: These are almost always problematic if the CHMs are not in the same folder as the CHM, because Microsoft's CHM system has a number of uncorrected bugs related to this (the CHM help system hasn't really been bug-fixed or updated since it was released with Windows 98).

The CHM skins included in the Premium Pack 2 add-on include automatic code that corrects and works around these bugs, allowing you to use relative paths to files with both file and Internet links in CHM files. If you are not using the Premium Pack the easiest solution is to use a file link and put the PDFs in the same folder as the CHM. Putting them anywhere else the links will almost always fail -- if not on your computer then on your users' macnhines.

[Thomas Grehl]

Hi Tim,

thanks for the prompt reply. We used to work around some of the bugs already using http://helpman.it-authoring.com/viewtop ... f=2&t=9987, so I am aware of the problems with "historic" CHM system in this and other situations. However, the baggage section is empty, so this is not the reason for including the PDF files.

I will have a look at the Premium Pack, thanks for refering to it - I thought this was only "design" related, not real functionality.

kind regards,
Thomas