http://www.thescripts.com/forum/thread164021.html
Re: Open PDF
<script src="http://www.thescripts.com/casus/as_column.js" language="JavaScript" type="text/javascript"></script> <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" language="JavaScript" type="text/javascript"></script> <script src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-8550604525820387&dt=1204965808250&lmt=1204965795&skip=2&num_ads=3&output=js&correlator=1204965806000&channel=5288019193&url=http%3A%2F%2Fwww.thescripts.com%2Fforum%2Fthread164021.html&ad_type=text&image_size=300x250&feedback_link=on&ref=http%3A%2F%2Fwww.google.com%2Fsearch%3Fhl%3Den%26newwindow%3D1%26client%3Dfirefox-a%26rls%3Dorg.mozilla%253Aen-US%253Aofficial%26hs%3DTHF%26q%3Dpython%2Blaunch%2Bpdf%2Bviewer%26btnG%3DSearch&frm=0&cc=100&ga_vid=1537605324.1204965806&ga_sid=1204965806&ga_hid=1371361238&flash=9.0.115&u_h=768&u_w=1024&u_ah=738&u_aw=1024&u_cd=32&u_tz=480&u_his=1&u_java=true&u_nplug=10&u_nmime=29" language="JavaScript1.1" type="text/javascript"></script>
Re: Re: Open PDF
Re: Re: Open PDF
Re: Re: Open PDF
Re: Re: Open PDF
Re: Re: Open PDF
Re: Re: Open PDF
"Paul Boddie" <paul@boddie.org.uk> writes:
[...][color=blue]
> 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/inde...470&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.[/color]
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
 |
Re: Open PDF
> 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
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
| |
Re: Re: Open PDF
Dan <dan@cellectivity.com> writes:[color=blue]
> 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.[/color]
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 <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
> 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.[/color]
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 <mwm@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
| |
Re: Re: Open PDF
On Thu, 22 Sep 2005 15:16:09 +0100, Dan <dan@cellectivity.com> declaimed
the following in comp.lang.python:
[color=blue][color=green]
> > I would like to know how to open a PDF document from a python script[/color]
>
> 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")[/color]
For Windows, os.startfile() may be better...
[color=blue][color=green][color=darkred]
>>> help(os.startfile)[/color][/color][/color]
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.
[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]
--[color=blue]
> ================================================== ============ <
> wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <[/color]
the following in comp.lang.python:
[color=blue][color=green]
> > I would like to know how to open a PDF document from a python script[/color]
>
> 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")[/color]
For Windows, os.startfile() may be better...
[color=blue][color=green][color=darkred]
>>> help(os.startfile)[/color][/color][/color]
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.
[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]
--[color=blue]
> ================================================== ============ <
> wlfraed@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> ================================================== ============ <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.netcom.com/> <[/color]
| |
Re: Re: Open PDF
Dennis Lee Bieber skrev:[color=blue]
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <dan@cellectivity.com> declaimed
> the following in comp.lang.python:
>[color=green][color=darkred]
> > > I would like to know how to open a PDF document from a python script[/color]
> >
> > 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):[/color]
>
> For Windows, os.startfile() may be better...[/color]
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/inde...470&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
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <dan@cellectivity.com> declaimed
> the following in comp.lang.python:
>[color=green][color=darkred]
> > > I would like to know how to open a PDF document from a python script[/color]
> >
> > 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):[/color]
>
> For Windows, os.startfile() may be better...[/color]
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/inde...470&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
| |
Re: Re: Open PDF
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:[color=blue]
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <dan@cellectivity.com> declaimed
> the following in comp.lang.python:
>[color=green][color=darkred]
> > > I would like to know how to open a PDF document from a python script[/color]
> >
> > 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")[/color]
>
> For Windows, os.startfile() may be better...
>[color=green][color=darkred]
> >>> help(os.startfile)[/color][/color]
> 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.
>[color=green][color=darkred]
> >>>[/color][/color][/color]
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:[color=blue]
> On Thu, 22 Sep 2005 15:16:09 +0100, Dan <dan@cellectivity.com> declaimed
> the following in comp.lang.python:
>[color=green][color=darkred]
> > > I would like to know how to open a PDF document from a python script[/color]
> >
> > 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")[/color]
>
> For Windows, os.startfile() may be better...
>[color=green][color=darkred]
> >>> help(os.startfile)[/color][/color]
> 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.
>[color=green][color=darkred]
> >>>[/color][/color][/color]
| |
Re: Re: Open PDF
"Martin Miller" <ggrp1.20.martineau@dfgh.net> writes:
[color=blue]
> 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.[/color]
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
[color=blue]
> 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.[/color]
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
| |
Re: Re: Open PDF
"Paul Boddie" <paul@boddie.org.uk> writes:
[...][color=blue]
> 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/inde...470&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.[/color]
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
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
