On Apr 5, 2007, at 7:49 AM, Robin Houston wrote:
This new version uses PDFTeX by default, and will try to use TeXShop as the previewer. (Note that TeXShop is part of MacTeX 2007.)
Have you looked at PDFView? http://pdfview.sourceforge.net/
The bundle is available (for the moment) here:
http://www.puffinry.demon.co.uk/LaTeX%20Watch%202.0.dmg
This version should be almost ready to be incorporated into the LaTeX bundle, so please let me know about any problems.
The default behaviour can be changed by setting shell variables, as follows:
- If TM_LATEX_VIEWER=TeXniscope, it will use TeXniscope instead of
TeXShop (If you should happen to want LaTeX Watch to use a different previewer from 'Compile and View', you can set TM_LATEX_WATCH_VIEWER=TeXShop to override the TM_LATEX_VIEWER setting.)
Is this TM_LATEX_WATCH_VIEWER variable really necessary?
- If TM_LATEX_WATCH_MODE=PS, then it will compile via DVI, and use
GV to preview.
- If TM_LATEX_WATCH_DEBUG=console, additional status messages will
be printed to the console; if TM_LATEX_WATCH_DEBUG=dialog, these status messages will pop up in dialog boxes.
Is there any way we can cut down on all those environment variables? The LaTeX bundle already uses more than it should. For instance there is already a TEX_PSTRICKS (hm, we should probably change that to TM_LATEX_PSTRICKS) which tells the LaTeX&View command to switch to going through ps. Perhaps you can use that instead of the TM_LATEX_WATCH_MODE?
And for the debug options, perhaps simply have only one: enabled or disabled? And simply force them to be on the console?
Incidentally, there is a utility in Support/bin/check_open that may be more generally useful. It uses the Carbon API to check whether a particular document is open in a particular application. (This is used to stop watching the document when you close its preview window.) Of course the same thing could be done with AppleScript, but that is too slow. (Another alternative would be to use the Perl-Carbon bindings that are included in 10.4, but that would not work on earlier OS versions.)
Since it's a bit of a pain to install GV, and since several widely- distributed versions have irritating bugs, I wondered about including a GV binary in the package. As an experiment, I built gv-3.5.8 as a universal binary with libXaw3d statically linked in, and it comes to about 3MB. Does anyone have an opinion on this?
The size is considerable. Perhaps we can just add instructions for installing it on the help page, or just make the above binary available somewhere?
What is the license on gv btw?
Robin
Haris Skiadas Department of Mathematics and Computer Science Hanover College