Re: Open PDF

10 views
Skip to first unread message

Dan

unread,
Sep 22, 2005, 10:16:09 AM9/22/05
to Jorge Ramirez, pytho...@python.org
> I would like to know how to open a PDF document from a python script

You mean open it and display it to the user? Under Windows you may be
able to get away with just "executing" the file (as though it were an
executable):

import os
os.system("c:/path/to/file.pdf")

Under Linux you can probably use xpdf or gpdf:

os.system("xpdf /path/to/file.pdf")

Note that you should check the return code of "system" to see if the
execution was successful. For example, the user might not have xpdf
installed.

--
Don't try to be charming, witty or intellectual. Just be yourself.
- Mrs. Cuomo's poorly worded advice to her husband (then
governor of New York) shortly before his speech to the
New York Press Club


Mike Meyer

unread,
Sep 22, 2005, 11:42:28 AM9/22/05
to
Dan <d...@cellectivity.com> writes:
> Under Linux you can probably use xpdf or gpdf:
>
> os.system("xpdf /path/to/file.pdf")
>
> Note that you should check the return code of "system" to see if the
> execution was successful. For example, the user might not have xpdf
> installed.

This is the problem that the "open" package was designed to
solve. The API for Python apps is still under development, but if you
do 'os.system("open /path/to/file.pdf")', open will use the users
preferred pdf viewer, and interact with the user to select one if they
don't have a prefernce on record.

<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

Message has been deleted

Paul Boddie

unread,
Sep 23, 2005, 12:42:49 PM9/23/05
to
Dennis Lee Bieber skrev:
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <d...@cellectivity.com> declaimed
> the following in comp.lang.python:

>
> > > I would like to know how to open a PDF document from a python script
> >
> > You mean open it and display it to the user? Under Windows you may be
> > able to get away with just "executing" the file (as though it were an
> > executable):
>
> For Windows, os.startfile() may be better...

I've just uploaded a patch/suggestion/module (#1301512) to SourceForge
which seeks to provide the equivalent of os.startfile for KDE and GNOME
(as well as Windows) as part of a generic desktop module:

http://sourceforge.net/tracker/index.php?func=detail&aid=1301512&group_id=5470&atid=305470

Rather than submit yet another PEP and argue about insignificant
details whilst the webbrowser module sits comfortably in the standard
library, failing to address general file-opening issues directly and
doing the wrong thing under various modern desktop environments, I
advocate people submitting suggestions, criticism and amendments to the
uploaded attachment until we have something like os.startfile for all
major desktop environments.

Paul

Martin Miller

unread,
Sep 23, 2005, 2:55:28 PM9/23/05
to
IMHO, the fact that there is no way to wait for the application to
finish is major deficiency with os.startfile() -- and why I often
cannot use it instead of other techniques [such as the much more
involved but limited os.spawnv() function].

I don't if if this is just a limitation of the implementation in the
Python os module or one with the underlying OS (Windoze) -- I suspect
the latter.

Regards,
-Martin


Dennis Lee Bieber wrote:
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <d...@cellectivity.com> declaimed
> the following in comp.lang.python:
>

> > > I would like to know how to open a PDF document from a python script
> >
> > You mean open it and display it to the user? Under Windows you may be
> > able to get away with just "executing" the file (as though it were an
> > executable):
> >
> > import os
> > os.system("c:/path/to/file.pdf")
>

> For Windows, os.startfile() may be better...
>

> >>> help(os.startfile)
> Help on built-in function startfile:
>
> startfile(...)
> startfile(filepath) - Start a file with its associated application.
>
> This acts like double-clicking the file in Explorer, or giving the
> file
> name as an argument to the DOS "start" command: the file is opened
> with whatever application (if any) its extension is associated.
>
> startfile returns as soon as the associated application is launched.
> There is no option to wait for the application to close, and no way
> to retrieve the application's exit status.
>
> The filepath is relative to the current directory. If you want to
> use
> an absolute path, make sure the first character is not a slash
> ("/");
> the underlying Win32 ShellExecute function doesn't work if it is.
>
> >>>

Thomas Heller

unread,
Sep 23, 2005, 3:54:54 PM9/23/05
to
"Martin Miller" <ggrp1.20....@dfgh.net> writes:

> IMHO, the fact that there is no way to wait for the application to
> finish is major deficiency with os.startfile() -- and why I often
> cannot use it instead of other techniques [such as the much more
> involved but limited os.spawnv() function].
>
> I don't if if this is just a limitation of the implementation in the
> Python os module or one with the underlying OS (Windoze) -- I suspect
> the latter.

os.startfile calls ShellExecute. AFAIK, if ShellExecuteEx were used,
this could retrieve a process handle which you could wait for os so.

With ctypes you can easily experiment with this kind of stuff. Another
interesting feature, imo, is the 'verb' that you can pass to these
functions. With this, you could for example specify 'print' to print the
file instead of just opening it.

Thomas

John J. Lee

unread,
Sep 24, 2005, 8:46:42 AM9/24/05
to pytho...@python.org
"Paul Boddie" <pa...@boddie.org.uk> writes:
[...]

> I've just uploaded a patch/suggestion/module (#1301512) to SourceForge
> which seeks to provide the equivalent of os.startfile for KDE and GNOME
> (as well as Windows) as part of a generic desktop module:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1301512&group_id=5470&atid=305470
>
> Rather than submit yet another PEP and argue about insignificant
> details whilst the webbrowser module sits comfortably in the standard
> library, failing to address general file-opening issues directly and
> doing the wrong thing under various modern desktop environments, I
> advocate people submitting suggestions, criticism and amendments to the
> uploaded attachment until we have something like os.startfile for all
> major desktop environments.

Nice. I've started the ball rolling with what I think is a KDE bug
fix (though I'm certain you know more about KDE than I do...), and
some comments on the tracker.


John

Reply all
Reply to author
Forward
0 new messages