Overriding pdfview

older
wrong space when compressseparator...

Bill Meahan

26 Jun 2013 26 Jun '13

7:53 a.m.

How does one override the default pdf viewer for MKIV Standalone on Windows 7-64 so --autopdf starts Acrobat Reader instead of "sumatrapdf.exe"? I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too. I have searched through the source and tried editing l-pdf.lua but that doesn't seem to fix the problem. I shouldn't have to edit system source in any event. Mark me frustrated. -- Bill Meahan Westland, Michigan "The nice thing about standards is there are so many of them." -- Henry Spencer

Show replies by date

luigi scarso

26 Jun 26 Jun

8:20 a.m.

On Wed, Jun 26, 2013 at 3:53 PM, Bill Meahan wrote:

...

How does one override the default pdf viewer for MKIV Standalone on Windows 7-64 so --autopdf starts Acrobat Reader instead of "sumatrapdf.exe"?

I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too.

I have searched through the source and tried editing l-pdf.lua but that doesn't seem to fix the problem. I shouldn't have to edit system source in any event.

Mark me frustrated.

I don't see l-pdf.lua in my standalone .

I don't use sumatra under linux but I see this tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = 'start "test" "c:/data/system/sumatrapdf/sumatrapdf.exe" -reuse-instance', tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = 'start "test" "sumatrapdf.exe" -reuse-instance -bg-color 0xCCCCCC', tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = false, tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = false, tex/texmf-context/tex/context/base/l-pdfview.lua: pdfview.method = "sumatra" tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = 'wine "sumatrapdf.exe" -reuse-instance -bg-color 0xCCCCCC', tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = false, tex/texmf-context/tex/context/base/l-pdfview.lua: ['sumatra'] = false, tex/texmf-context/tex/context/base/l-pdfview.lua: pdfview.method = "sumatra" tex/texmf-context/context/data/scite/scite-context.properties: name.flag.pdfopen=--autopdf=sumatra In l-pdfview.lua I argue that pdfview.method = "acrobat" can help . If you are using scite, then the file is probably tex/texmf-context/context/data/scite/scite-context.properties -- luigi

Bill Meahan

9:17 a.m.

On 6/26/2013 10:20 AM, luigi scarso wrote:

...

On Wed, Jun 26, 2013 at 3:53 PM, Bill Meahan mailto:subscribed_lists@meahan.net> wrote:

How does one override the default pdf viewer for MKIV Standalone on Windows 7-64 so --autopdf starts Acrobat Reader instead of "sumatrapdf.exe"?

I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too.

I have searched through the source and tried editing l-pdf.lua but that doesn't seem to fix the problem. I shouldn't have to edit system source in any event.

Mark me frustrated.

I don't see l-pdf.lua in my standalone .

TYPO: It's l-pdfview.lua sometimes my memory.... From my standalone (updated yesterday) ..[snip].. if os.type == "windows" then opencalls = { ['default'] = "pdfopen --rxi --file", ['acrobat'] = "pdfopen --rxi --file", ['fullacrobat'] = "pdfopen --axi --file", ['okular'] = 'start "test" "c:/data/system/kde/bin/okular.exe" --unique', -- todo! ['sumatra'] = 'start "test" "c:/data/system/sumatrapdf/sumatrapdf.exe" -reuse-instance', ['okular'] = 'start "test" "okular.exe" --unique', ['sumatra'] = 'start "test" "sumatrapdf.exe" -reuse-instance -bg-color 0xCCCCCC', } closecalls= { ['default'] = "pdfclose --file", ['acrobat'] = "pdfclose --file", ['okular'] = false, ['sumatra'] = false, } allcalls = { ['default'] = "pdfclose --all", ['acrobat'] = "pdfclose --all", ['okular'] = false, ['sumatra'] = false, } pdfview.method = "acrobat" -- no longer useful due to green pop up line and clasing reader/full pdfview.method = "sumatra" <=========================== runner = function(cmd) os.execute(cmd) -- .. " > /null" end else ..[snip].. Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files. -- Bill Meahan Westland, Michigan "The nice thing about standards is there are so many of them." --Henry Spencer

luigi scarso

10:11 a.m.

On Wed, Jun 26, 2013 at 5:17 PM, Bill Meahan wrote:

...

On 6/26/2013 10:20 AM, luigi scarso wrote:

On Wed, Jun 26, 2013 at 3:53 PM, Bill Meahan wrote:

...
How does one override the default pdf viewer for MKIV Standalone on Windows 7-64 so --autopdf starts Acrobat Reader instead of "sumatrapdf.exe"?

I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too.

I have searched through the source and tried editing l-pdf.lua but that doesn't seem to fix the problem. I shouldn't have to edit system source in any event.

Mark me frustrated.

I don't see l-pdf.lua in my standalone .

TYPO: It's l-pdfview.lua sometimes my memory....

From my standalone (updated yesterday)

..[snip].. if os.type == "windows" then

opencalls = { ['default'] = "pdfopen --rxi --file", ['acrobat'] = "pdfopen --rxi --file", ['fullacrobat'] = "pdfopen --axi --file", ['okular'] = 'start "test" "c:/data/system/kde/bin/okular.exe" --unique', -- todo!

['sumatra'] = 'start "test" "c:/data/system/sumatrapdf/sumatrapdf.exe" -reuse-instance', ['okular'] = 'start "test" "okular.exe" --unique',

['sumatra'] = 'start "test" "sumatrapdf.exe" -reuse-instance -bg-color 0xCCCCCC', } closecalls= { ['default'] = "pdfclose --file", ['acrobat'] = "pdfclose --file", ['okular'] = false, ['sumatra'] = false, } allcalls = { ['default'] = "pdfclose --all", ['acrobat'] = "pdfclose --all", ['okular'] = false, ['sumatra'] = false, }

pdfview.method = "acrobat" -- no longer useful due to green pop up line and clasing reader/full pdfview.method = "sumatra" <===========================

runner = function(cmd) os.execute(cmd) -- .. " > /null" end

else ..[snip]..

Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files.

maybe context --autopdf=acrobat context --autopdf=fullacrobat -- luigi

Hans Hagen

1:29 p.m.

On 6/26/2013 6:11 PM, luigi scarso wrote:

...

On Wed, Jun 26, 2013 at 5:17 PM, Bill Meahan

...
I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too.

- on none of my window boxes acrobat was preinstalled - there is no robust way to start acrobat - pdfopen has to be adapted to major updates of acrobat - there is (at least on my machine) a potential clash between reader and professional - acrobat occasionally tends to block - the latest version of acrobat has funny popups when opening docs while sumatrapdf - is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux) so, enough reasons for me to have changed the defaults (esp because one can always set different defaults)

...

Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files.

maybe context --autopdf=acrobat context --autopdf=fullacrobat

or in a scite user properties file: if PLAT_WIN name.flag.pdfopen=--autopdf=acrobat ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

luigi scarso

2:22 p.m.

On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...

while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux . Now that I have done a luatex binding for mupdf, if we have a minimal GUI toolkit cross platform (but really minimal) it's possible to build a pdfviewer in luatex (ok I think that it's quite slow). -- luigi

Siep Kroonenberg

2:36 p.m.

On Wed, Jun 26, 2013 at 10:22:23PM +0200, luigi scarso wrote:

...

On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

For Linux, have a look at qpdfview. -- Siep Kroonenberg

luigi scarso

3:09 p.m.

On Wed, Jun 26, 2013 at 10:36 PM, Siep Kroonenberg wrote:

...

On Wed, Jun 26, 2013 at 10:22:23PM +0200, luigi scarso wrote:

...
On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be

recolored)

...
- can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

For Linux, have a look at qpdfview.

ok I in stalled, I will play with it a bit. -- luigi

Philipp Gesang

2:50 p.m.

Hi Luigi! ·········

...

On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

Now that I have done a luatex binding for mupdf, if we have a minimal GUI toolkit cross platform (but really minimal) it's possible to build a pdfviewer in luatex

If you’re serious about this, the Zathura guys have a separate interface library based on GTK [1]. Having some (any) Lua capability inside a pdf viewer would indeed be nice. Best, Philipp [1] http://pwmt.org/projects/girara/.

Hans Hagen

2:58 p.m.

On 6/26/2013 10:50 PM, Philipp Gesang wrote:

...

Hi Luigi!

·········

...
On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

Now that I have done a luatex binding for mupdf, if we have a minimal GUI toolkit cross platform (but really minimal) it's possible to build a pdfviewer in luatex

If you’re serious about this, the Zathura guys have a separate interface library based on GTK [1]. Having some (any) Lua capability inside a pdf viewer would indeed be nice.

FYI: After Luigi and I have wrapped up the projects "swiglib" (libraries) and "speed-up-luatex" projects we will start our "lua-in-pdf-viewer" exploration (after all pdf permits additional annotations) ... and we need challenges. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

luigi scarso

3:16 p.m.

On Wed, Jun 26, 2013 at 10:58 PM, Hans Hagen wrote:

...

On 6/26/2013 10:50 PM, Philipp Gesang wrote:

...
Hi Luigi!

·········

On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

Now that I have done a luatex binding for mupdf, if we have a minimal GUI toolkit cross platform (but really minimal) it's possible to build a pdfviewer in luatex

If you’re serious about this, the Zathura guys have a separate interface library based on GTK [1]. Having some (any) Lua capability inside a pdf viewer would indeed be nice.

FYI: After Luigi and I have wrapped up the projects "swiglib" (libraries) and "speed-up-luatex" projects we will start our "lua-in-pdf-viewer" exploration (after all pdf permits additional annotations) ... and we need challenges.

Hans

yes, approximately/hopefully end of next year, and suggestions are all welcome, of course --- and the meeting is a nice place to discuss these kind of things. Of course a good solution has small size, it is fast and works in the same way at least under Windows/Linux/Mac. -- luigi

Philipp Gesang

3:34 p.m.

·········

...

On 6/26/2013 10:50 PM, Philipp Gesang wrote:

...
Hi Luigi!

·········

...
On Wed, Jun 26, 2013 at 9:29 PM, Hans Hagen wrote:

...
while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

I have to admit that I often think to a context pdf viewer, and mupdf

seems the right candidate. Under ubuntu 64bit 12.04 xpdf doesn't work, acroreader is still 9 32 bit (so I use wine acroreader 11) evince is ok, probably also okular. A context pdf viewer should be like sumatrapdf at least --- so in the end I also installed sumatrapdf.exe under linux .

Now that I have done a luatex binding for mupdf, if we have a minimal GUI toolkit cross platform (but really minimal) it's possible to build a pdfviewer in luatex

If you’re serious about this, the Zathura guys have a separate interface library based on GTK [1]. Having some (any) Lua capability inside a pdf viewer would indeed be nice.

FYI: After Luigi and I have wrapped up the projects "swiglib" (libraries) and "speed-up-luatex" projects we will start our "lua-in-pdf-viewer" exploration (after all pdf permits additional annotations) ... and we need challenges.

Do you plan on making the PDF internals as transparent and easy to manipulate as Luatex does with TeX? Looking forward to it! Best, Philipp

...

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Sietse Brouwer

27 Jun 27 Jun

9:15 a.m.

Instead of choosing our own default PDF viewer, we should probably invoke the user's default PDF viewer. Every OS has a command-line program to open a file with the system default program: On OS X: open myfile.pdf On Windows: start myfile.pdf On Linux, there separate programmes for KDE, new gnome and old gnome, and desktop-agnostic: kde-open myfile.pdf || gvfs-open myfile.pdf || gnome-open myfile.pdf || xdg-open myfile.pdf Cheers, Sietse

Mica Semrick

9:44 a.m.

...

On Linux, there separate programmes for KDE, new gnome and old gnome, and desktop-agnostic: kde-open myfile.pdf || gvfs-open myfile.pdf || gnome-open myfile.pdf || xdg-open myfile.pdf

On my linux mint/debian boxes, xdg-open works fine across MATE, XFCE, and KDE. On Thu, Jun 27, 2013 at 8:15 AM, Sietse Brouwer wrote:

...

Instead of choosing our own default PDF viewer, we should probably invoke the user's default PDF viewer. Every OS has a command-line program to open a file with the system default program:

On OS X: open myfile.pdf

On Windows: start myfile.pdf

On Linux, there separate programmes for KDE, new gnome and old gnome, and desktop-agnostic: kde-open myfile.pdf || gvfs-open myfile.pdf || gnome-open myfile.pdf || xdg-open myfile.pdf

Cheers, Sietse

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net

___________________________________________________________________________________

Aditya Mahajan

11:25 a.m.

On Thu, 27 Jun 2013, Sietse Brouwer wrote:

...

Instead of choosing our own default PDF viewer, we should probably invoke the user's default PDF viewer. Every OS has a command-line program to open a file with the system default program:

On OS X: open myfile.pdf

On Windows: start myfile.pdf

On Linux, there separate programmes for KDE, new gnome and old gnome, and desktop-agnostic: kde-open myfile.pdf || gvfs-open myfile.pdf || gnome-open myfile.pdf || xdg-open myfile.pdf

Or, simple read the mailcap preference or use a program such as run-mailcap or see which choose the viewer based on mailcap preferences. I am half joking here; don't go down this route. One can simply leave it to the user to write a wrapper to context that calls the PDF viewer when context is finished. Aditya

Arthur Reutenauer

1:39 p.m.

...

I am half joking here; don't go down this route.

Why? Users can override defaults, but most don't (and most certainly not by writing additional code themselves, except for a tiny minority). Why shouldn't reasonable defaults be provided? Arthur

Hans Hagen

12:18 p.m.

On 6/27/2013 5:15 PM, Sietse Brouwer wrote:

...

Instead of choosing our own default PDF viewer, we should probably invoke the user's default PDF viewer. Every OS has a command-line program to open a file with the system default program:

On OS X: open myfile.pdf

On Windows: start myfile.pdf

On Linux, there separate programmes for KDE, new gnome and old gnome, and desktop-agnostic: kde-open myfile.pdf || gvfs-open myfile.pdf || gnome-open myfile.pdf || xdg-open myfile.pdf

but there is no stop myfile.pdf restart myfile.pdf ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Bill Meahan

26 Jun 26 Jun

3:27 p.m.

On 6/26/2013 3:29 PM, Hans Hagen wrote: ............[snip]...................

...

- on none of my window boxes acrobat was preinstalled - there is no robust way to start acrobat - pdfopen has to be adapted to major updates of acrobat - there is (at least on my machine) a potential clash between reader and professional - acrobat occasionally tends to block - the latest version of acrobat has funny popups when opening docs

while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

sumatrapdf may be the best PDF viewer ever invented. As a lawyer might say, "I'll stipulate that." If someone who wants to use ConTeXt has never heard of it and has to use a search engine to even know what it is, however, it's not a great default to have on a *public* distribution. Similar arguments could be made for Calibre (which I use).

...

so, enough reasons for me to have changed the defaults (esp because one can always set different defaults)

That was my original question: how do I change the default without hand-editing a file in the base distribution? That's not only bad practice, it's liable to get overwritten on the "next" update. Does one use texmf.cnf or something else with a very recent MKIV?

...

...
Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files.

I haven't settled on SciTE as the editor I want to use but a SciTE-only workaround misses the point.

...

...
maybe context --autopdf=acrobat context --autopdf=fullacrobat

When run from the cmd.exe command line, acrobat _does_ get launched _but_ it gets launched before ConTeXt has created the pdf file then hangs so the only way to exit is a Ctrl-C in the cmd.exe window. Simply closing acrobat simply causes acrobat to launch again. A better solution would be to assume the person installing ConTeXt does not have a PDF reader *at all* and include some minimal self-contained reader (no dll's needed) in the distribution itself, the way rsync is included. I really don't care which one, as long as there is *something* present. MuPDF might be a good choice but I'm quite sure everyone on the list has a favorite they would like to see as the "included" viewer for one reason or another. As long as ConTeXt is guaranteed to find it, it is a good default.

Hans Hagen

4:24 p.m.

On 6/26/2013 11:27 PM, Bill Meahan wrote:

...

That was my original question: how do I change the default without hand-editing a file in the base distribution? That's not only bad practice, it's liable to get overwritten on the "next" update.

as mentioned in an earlier mail ... you can set it in a user properties file and the last settings loaded are taken (which happen to be user properties)

...

Does one use texmf.cnf or something else with a very recent MKIV?

...
...
Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files.

I haven't settled on SciTE as the editor I want to use but a SciTE-only workaround misses the point.

in any editor, when one wants to run context, mtxrun --script context has to be configured and adding --autopdf=acrobat is then no big deal

...

...
...
maybe context --autopdf=acrobat context --autopdf=fullacrobat

When run from the cmd.exe command line, acrobat _does_ get launched _but_ it gets launched before ConTeXt has created the pdf file then hangs so the only way to exit is a Ctrl-C in the cmd.exe window. Simply closing acrobat simply causes acrobat to launch again.

it has to do with the fact that only files opened with pdfopen.exe can be closed with pdfclose.exe .. both programs already have to jump through loops to get that done

...

A better solution would be to assume the person installing ConTeXt does not have a PDF reader *at all* and include some minimal self-contained reader (no dll's needed) in the distribution itself, the way rsync is included. I really don't care which one, as long as there is *something* present. MuPDF might be a good choice but I'm quite sure everyone on the list has a favorite they would like to see as the "included" viewer for one reason or another. As long as ConTeXt is guaranteed to find it, it is a good default.

i suppose that summatrapdf can be put in the texmf-mswin/bin path .. after all. the portable version is not depending on other components btw, is nothing is present, context will still run ok with --autopdf ... okay one will need a printer then as said: acrobat just became too inconvenient for me to use in a fast edit/view cycle (pop ups, dialogs, conflicts between professional and reader, etc. makes me wonder where it's heading); i still use professional for proofing, inspection and presentations (when some javascript related features and/or layers and/or structure is needed). Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Bill Meahan

5:02 p.m.

On 6/26/2013 6:24 PM, Hans Hagen wrote: ........................[snip]......................... If there is one thing I have learned in developing software since 1965 (not a typo), it is to never depend on /any /third-party application being present. If it is not part of the base system install, it probably won't be there. I've even met Unix systems without /make/. Requiring the user to use some flag or other seldom flies and results in many nastygrams and late-night phone calls. If you need it, include it. I pass on this group of scars on my butt for what it's worth and declare the topic closed. -- Bill Meahan Westland, Michigan "The nice thing about standards is there are so many of them." -- Henry Spencer

luigi scarso

27 Jun 27 Jun

1:21 a.m.

On Thu, Jun 27, 2013 at 1:02 AM, Bill Meahan wrote:

...

On 6/26/2013 6:24 PM, Hans Hagen wrote: ........................[snip].........................

If there is one thing I have learned in developing software since 1965 (not a typo), it is to never depend on *any *third-party application being present. If it is not part of the base system install, it probably won't be there. I've even met Unix systems without *make*. Requiring the user to use some flag or other seldom flies and results in many nastygrams and late-night phone calls. If you need it, include it.

yes , this is how currently the standalone core context --- and in the end, also the texlive -- works, with the constrain that it has to work with the same results on several different platforms. This means that the viewer cannot be part of the core -- it's the same situation of inkscape for svg. But instead of give no support at all sometime is better to give some support, if possibile -- for example if it's easy to install a pdf viewer or inkscape.

-- luigi

hwitloc＠gmail.com

26 Jun 26 Jun

8:21 p.m.

I likewise find the Sumatr pdf viewer better. Besides the benefits already mentioned, it also has the proper quality of being non-intrusive. Adobe readers are quite happy to bloat your memory and take control or otherwise intrude on your system's normal operations. I don't use Adobe's reader at all. Cheers Hans Hagen wrote:

...

On 6/26/2013 6:11 PM, luigi scarso wrote:

...
On Wed, Jun 26, 2013 at 5:17 PM, Bill Meahan

...
I don't have "sumatra" and do not wish to install it just to satisfy this one application. WTH is it anyway? (I know what it is, it's a rhetorical question). Making some obscure pdf viewer the default with no clear way to change it is not a good idea. For Windows, the vast majority of people have Acrobat Reader which is very often preinstalled. For Linux, it's less clear what the default should be but {xpdf |evince|acroread} are quite common. Can't speak to OSX as I've never used it but I'd bet a coffee Acrobat Reader is (or can be) there, too.

- on none of my window boxes acrobat was preinstalled - there is no robust way to start acrobat - pdfopen has to be adapted to major updates of acrobat - there is (at least on my machine) a potential clash between reader and professional - acrobat occasionally tends to block - the latest version of acrobat has funny popups when opening docs

while sumatrapdf

- is pretty fast - has matured quite well - remembers the current page - renders quite ok - even supports some basic interactivity - (has an ugly yellow pop up windows but those can nowadays be recolored) - can be installed as portable application - works ok wine/linux (in fact has my preference now when on linux)

so, enough reasons for me to have changed the defaults (esp because one can always set different defaults)

...
Although I first discovered this when trying to use SciTE, it does the same thing if invoked from the command line. The pdf viewer does not appear in any of the SciTE *.properties files.

maybe context --autopdf=acrobat context --autopdf=fullacrobat

or in a scite user properties file:

if PLAT_WIN name.flag.pdfopen=--autopdf=acrobat

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

luigi scarso

27 Jun 27 Jun

1:35 a.m.

On Thu, Jun 27, 2013 at 4:21 AM, wrote:

...

I likewise find the Sumatr pdf viewer better. Besides the benefits already mentioned, it also has the proper quality of being non-intrusive. Adobe readers are quite happy to bloat your memory and take control or otherwise intrude on your system's normal operations.

I don't use Adobe's reader at all.

Adobe Reader/Acrobat is the reference: is you see and print a pdf with Acrobat under Windows 8 you are on the right side. Otherwise you are on the wrong side. For javascript, if the pdf works under Acrobat under Windows 8 it's ok, otherwise no. If Reader/Acrobat doesn't complain the question if the pdf is valid or not is not important for and end user (ok, it's not true for pdf/a). Until now I have found the sumatrapdf is (very) good, but it cannot be used as reference. -- luigi

Hans Hagen

2:13 a.m.

On 6/27/2013 9:35 AM, luigi scarso wrote:

...

On Thu, Jun 27, 2013 at 4:21 AM, mailto:hwitloc@gmail.com> wrote:

I likewise find the Sumatr pdf viewer better. Besides the benefits already mentioned, it also has the proper quality of being non-intrusive. Adobe readers are quite happy to bloat your memory and take control or otherwise intrude on your system's normal operations.

I don't use Adobe's reader at all.

Adobe Reader/Acrobat is the reference: is you see and print a pdf with Acrobat under Windows 8 you are on the right side. Otherwise you are on the wrong side. For javascript, if the pdf works under Acrobat under Windows 8 it's ok, otherwise no.

If Reader/Acrobat doesn't complain the question if the pdf is valid or not is not important for and end user (ok, it's not true for pdf/a).

indeed, it's the final reference

...

Until now I have found the sumatrapdf is (very) good, but it cannot be used as reference.

but okay and convenient for edit/view cycles (my second choice is okular, also available for windows) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

4037

Age (days ago)

4038

Last active (days ago)

List overview

Download

23 comments

10 participants

participants (10)

Aditya Mahajan
Arthur Reutenauer
Bill Meahan
Hans Hagen
hwitloc＠gmail.com
luigi scarso
Mica Semrick
Philipp Gesang
Siep Kroonenberg
Sietse Brouwer