Alternative viewer for Stata's PDF documentation

[Dirk Enzmann]

I know that StataCorp recommends using Adobe Reader to view Stata's PDF documentation (see "What are the recommended PDF viewer settings for Stata documentation?").

However, there are several reasons why I stopped using it as my standard .pdf-viewer. Among others, unpredictably but too often the recent versions of the Adobe Reader let freeze my printer driver (I am a Windows 7 user) after printing .pdf-documents. This problem has also been reported elsewhere and since a long time, but is still not solved.

To me a very convenient alternative is SumatraPDF. However, when defining this program as standard .pdf-viewer, using links from Stata's help window to Stata's PDF documentation will not work as it should: Although the correct .pdf-file will be opened by SumatraPDF, it will not jump automatically to the correct entry -- I have to search for the entry / page by myself.

Eight years ago, Hiroyuki Kawakatsu posted in Statalist a solution for xpdf on Linux ("using non-acroread viewer for pdf docs"). However, I don't understand how I could make use of his suggestion (for example, I can't find any stata_pdf script in my installation dir) and suspect that it refers to Linux installations of Stata.

Does anybody know a solution to my problem? Ideally allowing the use of SumatraPDF as a viewer for Stata's PDF documentation, but I would also be happy if I could keep SumatraPDF as standard viewer and use the Adobe Reader for Stata's PDF documentation, only.

[George Hoffman]

dirk - i settled on foxit reader for adobe-alternative pdf viewing. it will follow hyperlinks in stata documentation. the documents have so many internal hyperlinks that they crash many pdf viewers (as you ave found out).
i know this is not a direct answer to your question but maybe give it a try.
$0.02

[Roman Mostazir]

I don't like Adobe either. I am a Mac user and use 'preview' for reading pdfs. What I usually do is google the documentation, for example searching margins stata will bring the 'margins' related pdf link as search result. My browser is set to open any pdf link with 'preview' and that provides a lot better experience of reading pdfs than Adobe Reader. But your point is right, there is no way (I haven't found) to bypass Adobe if you are trying to read the pdfs within Stata environment.

[wbuchanan]

Dirk Enzmann do you have similar issues using Adobe Reader DC (the newest reader tool that they've released/published)? I use it on OSX and on non-*nix systems at work and have not had any issues with it. It looks much more like a web-based application, but I've not run into problems with it crashing or not being able to handle the internal hyperlinks.

[Daniel Bela]

I'd like to second Dirk Enzmann's question. It would be really helpful to be able to configure the parameters (and choose the application at all) invoked when accessing a link to the PDF documentation from within Stata. There's plenty of environments out there where Stata users (due to company restrictions or similar) are not able to use Adobe products, but have to stick with any other kind of PDF viewer.

George Hoffman, wbuchanan please note: SumatraPDF (and the like) work seamlessly with the crosslinks inside the PDF documentation itself, this is not the problem. It's the link from Stata's inline help files in the viewer window that is bugging us. Stata for Windows obviously calls the PDF viewer with parameters (in order to jump directly to a section/page inside the PDFs) that only Adobe Acrobat/Adobe reader understands.

The solution Dirk found in the Statalist archives still is working under Linux environments (and probably also under Mac OS), but stata_pdf is a shell script which is no present in Stata for Linux, thus not configurable by Stata users under Windows. All we would need is change the parameters passed to the PDF viewer, as we do in Unix by modifying stata_pdf.

Dirk, do you think this is a possible candidate for the Stata 15 wish list?

Regards
Bela

[Dirk Enzmann]

wbuchanan : No, I did not try after spending hours to locate the problem in recent Adobe Reader versions and I must say that I am fed up with Adobe Readers pressure to constantly update to newer versions with features (?) not useful to me. What I am looking for is a (c)lean, simple, and reliable tool for simply viewing .pdf-files. I don't want to play guinea pig for Adobe.

Daniel Bela : I followed George Hoffman 's suggestion and tried Foxit. The problem I experienced with SumatraPDF doesn't show up here, thus, not only Adobe understands the parameters Stata is using when calling the .pdf-viewer. The advantage of SumatraPDF is that you can use it as .pdf-viewer for .pdf-documents produced by LaTeX (it can co-operate with TexStudio) -- you need not to close the .pdf-file before replacing it by a new version. But this comes with the price that large documents take much longer to open with SumatraPDF. If my first impression of Foxit will not become disappointed, I think I would like to stay with it.

And yes, the issue of enabling the use of alternative .pdf-viewers is definitely a candidate for the Stata wish list - whether for Stata 15 or beyond.

[Daniel Bela]

Daniel Bela : I followed George Hoffman 's suggestion and tried Foxit. The problem I experienced with SumatraPDF doesn't show up here, thus, not only Adobe understands the parameters Stata is using when calling the .pdf-viewer. The advantage of SumatraPDF is that you can use it as .pdf-viewer for .pdf-documents produced by LaTeX (it can co-operate with TexStudio) -- you need not to close the .pdf-file before replacing it by a new version. But this comes with the price that large documents take much longer to open with SumatraPDF. If my first impression of Foxit will not become disappointed, I think I would like to stay with it.
[...]

It seems Stata calls the default PDF viewer and opens it using the command line arguments

/A page=# "FILENAME"

(if the link contains a page number # as jump target) or

/A nameddest=TARGET "FILENAME"

(if the link contains a named section TARGET as jump target).

SumatraPDF (as opposed to Foxit and Adobe Reader/Adobe Acrobat) obviously does not understand this, but would expect

-page # "FILENAME"

or

-named-dest TARGET "FILENAME"

, respectively.

In Stata for Linux, the stata_pdf shell script enables us to modify the parameters used; I don't see a similar configuration option for Windows. I will post this to the Wish list.

Regards
Bela