Problem linking from HTML to a specific PDF page destination

Problem linking from HTML to a specific PDF page/destination

We have an on-again/off-again problem with links from HTML to
desinations in a PDF.  Here's some background.

There are three computing environments involved here: my  company
(we produced XML, XSL, and PDF), our clients (pharma  companies),
and the FDA, which uses the XML, etc. we produce for our  clients
as part of their drug review process).

In our environment  (that is, purely in-house), everything  looks
fine: the XSL  transforms the XML into nice-looking HTML and  the
links to the  PDF work  as  expected.  For instance,  a link that
says "Adverse Events, pg 43" will take the user to page 43 of the
PDF (destination  name=p43). Since the  XML and  the PDF  must be
in    the     same   directory,    the    links   are     simple:
href=blankCRF.pdf#p43  (we don't  have  to deal with  UNC   names
and  can't  take advantage  of  using HTTP  file naming).

However, when we send the complete package - XML, XSL, CSS,  PDF,
and other  support files  - to  the client,  the links  SOMETIMES
work.  They will  ALWAYS open  the PDF,  but depending  on which
client we  send the  files to,  the PDF  will either  open to the
correct page or, incorrectly, to page 1.

This, understandably, makes the  client nervous, since they  want
the reviewer at the FDA to  be able to open to the  correct page.
Fortunately, the  FDA knows  that there  are known  "issues" with
HTML linkage  to PDF  destinations, and  so doesn't  require that
links open to specific locations in the PDF.  Despite this,  we'd
like to be able tell the client why, exactly, they can or  cannot
link correctly.

Here's how we're set up:
=> Internet Explorer V7 (we don't write the XSL to work with other
browsers)
=> PDF file being linked to is Version 1.6 (Acrobat 7.x)
=> Acrobat 7 Standard
=> Acrobat Reader version 8.1.2
=> PlugIn AcroIEhelper.dll, version 7.0.7.142
=> Windows XP Professional version 5.1.2600
=> IE opens PDFs using the plug-in, rather than Acrobat or Reader
=> Links cannot use UNC, HTTP:, or FILE: naming.

A recent client  had nearly the  same configuration but  couldn't
open the PDF to a link-specified page.  They were using the  same
version of IE, ran Windows XP Pro, etc.  The only difference  was
AcroIEhelper (Version 7.0.9, v.  our 7.0.7). When they  unchecked
"Display PDF in  browser" in Acrobat  6, the PDF  still opened to
page 1  rather than  page "not-1".   Nothing else  they tried was
successful in making the link  open to someplace other than  page
1.

So my questions  become: is there  something else that  we should
have been  looking at  and comparing?   Is there  a site/document
somewhere that says "these  combinations of PDF version,  plug-in
version, [etc.] have known issues when trying to link to specific
pages."  All we want to do is be able to tell the client & FDA in
advance that if  they have a  particular combination of  Acrobat,
plug-in, etc. that they will likely have problems with linking.

Thanks in advance for your input.

Frank DiIorio
CodeCrafters, Inc.

Problem linking from HTML to a specific PDF page/destination

We have an on-again/off-again problem with links from HTML to
desinations in a PDF.  Here's some background.

There are three computing environments involved here: my  company
(we produced XML, XSL, and PDF), our clients (pharma  companies),
and the FDA, which uses the XML, etc. we produce for our  clients
as part of their drug review process).

In our environment  (that is, purely in-house), everything  looks
fine: the XSL  transforms the XML into nice-looking HTML and  the
links to the  PDF work  as  expected.  For instance,  a link that
says "Adverse Events, pg 43" will take the user to page 43 of the
PDF (destination  name=p43). Since the  XML and  the PDF  must be
in    the     same   directory,    the    links   are     simple:
href=blankCRF.pdf#p43  (we don't  have  to deal with  UNC   names
and  can't  take advantage  of  using HTTP  file naming).

However, when we send the complete package - XML, XSL, CSS,  PDF,
and other  support files  - to  the client,  the links  SOMETIMES
work.  They will  ALWAYS open  the PDF,  but depending  on which
client we  send the  files to,  the PDF  will either  open to the
correct page or, incorrectly, to page 1.

This, understandably, makes the  client nervous, since they  want
the reviewer at the FDA to  be able to open to the  correct page.
Fortunately, the  FDA knows  that there  are known  "issues" with
HTML linkage  to PDF  destinations, and  so doesn't  require that
links open to specific locations in the PDF.  Despite this,  we'd
like to be able tell the client why, exactly, they can or  cannot
link correctly.

Here's how we're set up:
=> Internet Explorer V7 (we don't write the XSL to work with other
browsers)
=> PDF file being linked to is Version 1.6 (Acrobat 7.x)
=> Acrobat 7 Standard
=> Acrobat Reader version 8.1.2
=> PlugIn AcroIEhelper.dll, version 7.0.7.142
=> Windows XP Professional version 5.1.2600
=> IE opens PDFs using the plug-in, rather than Acrobat or Reader
=> Links cannot use UNC, HTTP:, or FILE: naming.

A recent client  had nearly the  same configuration but  couldn't
open the PDF to a link-specified page.  They were using the  same
version of IE, ran Windows XP Pro, etc.  The only difference  was
AcroIEhelper (Version 7.0.9, v.  our 7.0.7). When they  unchecked
"Display PDF in  browser" in Acrobat  6, the PDF  still opened to
page 1  rather than  page "not-1".   Nothing else  they tried was
successful in making the link  open to someplace other than  page
1.

So my questions  become: is there  something else that  we should
have been  looking at  and comparing?   Is there  a site/document
somewhere that says "these  combinations of PDF version,  plug-in
version, [etc.] have known issues when trying to link to specific
pages."  All we want to do is be able to tell the client & FDA in
advance that if  they have a  particular combination of  Acrobat,
plug-in, etc. that they will likely have problems with linking.

Thanks in advance for your input.

Frank DiIorio
CodeCrafters, Inc.