A summary of things people have said in this thread. NB: everything is paraphrased, so blame me if anything seems overly terse in tone. ---- Bill doesn't have or want SumatraPDF Hans made SumatraPDF the default because it has lots of nice properties that Acrobat doesn't have Luigi thinks maybe mupdf is the right candidate (evince and okular are OK, xpdf doesn't work under 64bit, linux acrobat is old) Siep uses qpdfview, perhaps? Suggests it Bill uses Calibre, personally (and he thinks it would also be bad if ConTeXt assumed everyone uses Calibre) Bill likes the idea of bundling a PDF reader with ConTeXt Hwitloc doesn't use Acrobat at all Luigi mentions that Adobe Reader is the reference PDF viewer -- what doesn't work in Adobe Reader might as well not work at all. Hans agrees Reader is the reference, but prefers sumatrapdf or okular for edit/view cycles Sietse thinks ConTeXt should start by using the user's default pdf viewer --- via open / start / xdg-open. It is then up to the user to override this setting for ConTeXt. Hans thinks this has a problem [on Windows?]: there is start myfile.pdf, but no stop myfile.pdf. Which doesn't play well with Adobe Reader, which cannot handle open PDFs being updated. Aditya proposes -- in jest -- to read the user's mailcap file (on Linux, presumably). Pavneet thinks there is merit in this 'read the user's mailcap' jest. Also, he likes evince. Luigi has found Evince sometimes has printing problems with PDFs make by MkIV ---- I'll repeat what I said, though: the PDF reader that is (a) most likely to be installed, and (b) is most logical / least surprising to the user, is: the user's own default PDF viewer. Adobe Reader may be clunky for this purpose, but IMO the user's choice should nonetheless be respected. It is easier, and less aggravating, to look up 'what is a better PDF viewer than Adobe' than 'why does ConTeXt not respect my default PDF viewer setting?' Cheers, Sietse

Hi All, I would agree that the users default should be respected. I will have to contradict my last post them. My suggestion them is to use a system variable such as ConTeXtViewer. This variable would contain the program to be called. If it is not set or empty context simply finishes up what ever it is doing and exits. It would not be two hard for a user to set this variable. Everybody gets what they want. It is not intrusive. It survives updates. Only needs to be done once. Now, if anybody wants to us the current method and furture versions he can or set up he wants. regards Keith. Am 28.06.2013 um 01:53 schrieb Gareth Jones :

...

I'll repeat what I said, though: the PDF reader that is (a) most likely to be installed, and (b) is most logical / least surprising to the user, is: the user's own default PDF viewer.

For what it’s worth, as an end user, I agree.

Hi Hans, I meant a OS system variable. But that actually does not matter. The default action would be changed to not call a browser! I agree that nobody should be forced to use autopdf. Yet, as I understand the discussion there seems to be a need to add some generality to the method. Possibly, a cleaner way to resolve this discussion is to define calls for user as in user defined. In other words, in addition to -autopdf there will be a parameter -autocalls which is a list of commands for the calls opencalls, closecalls, allcalls. No for more need for anyone to really change a file it would be in their call to context. regards Keith. Am 28.06.2013 um 12:34 schrieb Hans Hagen :

On 6/28/2013 10:56 AM, Keith J. Schultz wrote:

...

Hi All,

I would agree that the users default should be respected.

I will have to contradict my last post them.

My suggestion them is to use a system variable such as ConTeXtViewer. This variable would contain the program to be called. If it is not set or empty context simply finishes up what ever it is doing and exits.

in that case it would be a directive in texmfcnf.lua (probably in the texmflocal instance) but when unset there still will be the default

no one is forced to use --autopdf and if someone doesn't want to pop up a browser one can simply nto use --autopdf

keep in mind that when a user uses --autopdf he/she probably knows what is needed can can as well pass some extra info [snip, snip]

On 6/28/2013 1:46 AM, Sietse Brouwer wrote:

I'll repeat what I said, though: the PDF reader that is (a) most likely to be installed, and (b) is most logical / least surprising to the user, is: the user's own default PDF viewer. Adobe Reader may be clunky for this purpose, but IMO the user's choice should nonetheless be respected.

It is easier, and less aggravating, to look up 'what is a better PDF viewer than Adobe' than 'why does ConTeXt not respect my default PDF viewer setting?'

well, is someone chooses 'default' i.e. --autopdf=default then the pdfopen and pdfclose commands are used and these will use the system defaults; i can add 'auto' to do 'start' and 'open' but i'm not going to bother then with something close (which isn't available on all systems anyway) to be honest. i wasn't aware if anyone using --autopdf anyway and i mostly made it for my own edit/view cycle with scite, and the defaults there are my personal ones and users can easilly override them in a user properties file (so anyone not satisfied with my choices can set the preference to --autopdf=default there and get whatever (probably acrobat) is set up there (and then start fighting version clash startup differences) i expect most users to use their personal favourite editor and be able to configure the run context command (and is one omits the --autopdf viewing is completely up to the editor / os: as said, i only added --autopdf because it's handy in scite) 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 -----------------------------------------------------------------

On Fri, Jun 28, 2013 at 4:29 AM, Arthur Reutenauer < arthur.reutenauer@normalesup.org> wrote:

...

Unfortunately my version of evince doesn't always print correctly a pdf made by context mkiv

\starttext $3v$ \par

$3\omega$

\stoptext

When I do print->preview, the math is not shown, and nothing is printed.

As has already been mentioned, this could simply be a font issue, or a silly mistake with the way some programs handle Unicode characters with codes over 65536.

it's a known problem http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697766 or http://markmail.org/thread/butajobguctljovt#query:+page:1+mid:3kbunxjsfo2vzj... and probably fixed in the next release of 12.04 https://launchpad.net/ubuntu/+source/poppler/0.22.4-0ubuntu1 (I have not checked) -- luigi