• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

How to use the acrobat URL Protocol?

Guest
Aug 19, 2016 Aug 19, 2016

Copy link to clipboard

Copied

I see that acrobat has registered the acrobat url protocol on my (Windows 10) machine.

I've tried creating hyperlinks on web pages with urls like:

acrobat:|c:\mydoc.pdf

acrobat://c:\mydoc.pdf

acrobat://c:/mydoc.pdf

acrobat:c:/mydoc.pdf

...etc.

In most cases, clicking the links DOES cause Acrobat to open, but it gives me a "The file name of directory name syntax is incorrect" message.

Does anyone know how to format URL to use the acrobat URL Protocol and have it actually open the document? I assume it must work if they bothered to register the protocol in the registry!

...of course I'd REALLY like it to work with a web address rather than a local file path, but, per my other question, I doubt that will be working any time soon!

Launching Acrobat (full version) with a URL in the Path

Thanks,

Chris

TOPICS
Acrobat SDK and JavaScript , Windows

Views

9.1K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Guest
Feb 08, 2017 Feb 08, 2017

Copy link to clipboard

Copied

From my experience acrobat: protocol does not work for opening PDF documents. One option is to use third-party product that opens documents from a web page: WebDAV Ajax Library. It can open PDF files in Adobe Acrobat DC as well as any other docs - txt, rtf, odt and office docs in associated application.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Dec 07, 2021 Dec 07, 2021

Copy link to clipboard

Copied

Resurrecting these threads years later so that this information is out there on the web SOMEwhere...

 

The problem itself is simple: 

 

  • Application protocol URIs pass the *whole* URI as the argument, not just the part you expect to be a parameter.  So when you form a link `acrobat:my.pdf`, what comes into the `HKEY_CLASSES_ROOT\acrobat\shell\open\command` as `%1` isn't `my.pdf`, but `acrobat:my.pdf`.
  • That's just how these have always worked, and apps that respond to them correctly have code to interpret that whole application URI properly, whereas it looks like acrobat (or at least, Reader DC 21.7.20099.454979, which is what I have access to at the moment) does not.  (Maybe that was the intent at some point of the `/u` switch that's also in that command reg_sz, which as far as I can see doesn't seem to do anything in the current version other than "pretend no argument was passed at all instead of erroring out about its format" 🙄)

 

Fixing this, however, was a bit of a pain. 

I want to be able to just set that reg_sz value on the target machines (perhaps via gpo or something), not have to have a wrapper file of any kind deployed on them to support it, so I had to figure out a way to get rid of the spurious `acrobat:` in the parameter just using a one-liner of whatever subset of windows shell syntax it would actually let me use... 

 

The result feels a bit idiosyncratic to me, as far as in-context usage of quote characters and late-bindings and lack of escaping and stuff are concerned, but this is verbatim what ended up working on Windows 10.18363.  YMMV, at the least depending on your acrobat executable path.

cmd /v:on /c "SET _invocation=%1 & "C:\program files\adobe\acrobat DC\acrobat\acrobat.exe" !_invocation:acrobat:=!"

 

So there that is......  

But uh, hey adobe, why don't you just, like, add the single line of code to actually support the `acrobat:` protocol you apparently insert into the windows registry...?  I was stunned to discover that Acrobat, even just Reader, smoothly handles editing PDFs directly in webDAV folders, including in SharePoint libraries with check-out/check-in functionality integrated right in - but only if you manually paste the URL into the file open dialog (or pass it as a command line parameter).  Letting web developers actually form the hyperlinks that would directly remotely open PDFs that way seems like a huge win, so why is this broken and undiscussed?

 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Dec 08, 2021 Dec 08, 2021

Copy link to clipboard

Copied

Help

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Feb 13, 2023 Feb 13, 2023

Copy link to clipboard

Copied

Any updates on this? Did you since get this working in another way. The above works good, as you pointed out "including in SharePoint libraries with check-out/check-in functionality integrated right in". Would be nice if the cmd window didn't open up though, figure anything out for that?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Feb 17, 2023 Feb 17, 2023

Copy link to clipboard

Copied

Refined this a bit rather than :

cmd /v:on /c "SET _invocation=%1 & "C:\program files\adobe\acrobat DC\acrobat\acrobat.exe" !_invocation:acrobat:=!"

Use:

cmd /v:on /c "SET _invocation=%1 & start "" "C:\program files\adobe\acrobat DC\acrobat\acrobat.exe" !_invocation:acrobat:=!"

That will make the CMD window not show.

 

Also deleting the key:

Computer\HKEY_CLASSES_ROOT\acrobat\shell\open\ddeexec

resolves issues with files not opening if Acrobat is already open.

Or just deleting the values for that key and subkeys.

 

The reg values do not persist through reseting the default handler. This can be resolved by changing permissions on the Key(s), but than updates fail. The command key survives updates and uninstalls/reinstalls but the ddeexec key resets with updates, breaking this if an acrobat window is already open. Still trying to figure this out.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Beginner ,
Feb 21, 2023 Feb 21, 2023

Copy link to clipboard

Copied

This resolves the above issues with updates, just use "adobe" in place of "acrobat" for the protocol.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\adobe]
@="URL:PDF Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\adobe\DefaultIcon]
@="C:\\Program Files\\Adobe\\Acrobat DC\\Acrobat\\Acrobat.exe"

[HKEY_CLASSES_ROOT\adobe\shell]
@="Open"

[HKEY_CLASSES_ROOT\adobe\shell\open]
@="Open with Adobe Acrobat"

[HKEY_CLASSES_ROOT\adobe\shell\open\command]
@="cmd /v:on /c \"SET _invocation=%1 & start \"\" \"C:\\program files\\adobe\\acrobat DC\\acrobat\\acrobat.exe\" !_invocation:adobe:=!\""

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Sep 11, 2023 Sep 11, 2023

Copy link to clipboard

Copied

LATEST

Thanks, its working on windows 11 22H2 and Adobe Acrobat reader 64bit 2023.003.20284.

Here was some example url that i used successfully: 

adobe:https://somefile.pdf

 

All the best,

Ariwibawa

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines