Thanks a lot Christiaan for your quick reply. > On AFP volumes we cannot use filesystem notifications to get notified about > this, so we just check the mod date every 2 sec. So it will be noted any time > between immediate and 2 secs. There is a Revert menu action, but that may not > always be active, because we first need to know whether there's something to > revert, there's no way we can change that. The strange thing is that sometimes a reload may actually take over 5 sec after the TeX run has finished; it turns out that the reload behaviour can be quite unpredictable. Therefore, I suggested that the user may benefit from the option to do the reload manually. Unfortunately, my 'Revert' menu is still greyed out after a TeX run, when the preference 'Check for file changes' is off. It would be nice to be able to access this menu permanently, also when Skim is not looking at modification dates.
> Also reloading on activating is not an option, because that would lead to > many unnecessary reloads. You should realize that reload feature is buggy by > design, simply because it is impossible to do 100% correct, and we would > rather not have it at all. I would not mind the unnecessary reloads as Skim does them very fast. I agree that this approach is not very elegant, but in my situation (working on a remote home directory served by AFP) this would be more effective than waiting for the reload to kick in automatically after an unpredictable number of seconds. > The best way, and the only correct way, to reload the file is to have it done > yourself using a script that combines the tex process and the revert. I see. The problem with this is is that in our situation TeX is running on the server and Skim is running on clients, so it is not easy to make these two processes communicate. Further, as I mentioned above, the 'Revert' is currently not available. >> (2) Another thing is that PDF-TeX Sync support (using synctex), which is >> working great in OS X, is broken in OS X Server. Is there a way to debug the >> synctex behaviour in OS X Server? I would be glad if I could be of any help >> to fix this issue. > > Here we don't really use any file system stuff, except the file mod date. So > I would not know why that should not be working. Are you putting the output > files in a different directory, i.e. is your synctex file in a different > directory from the pdf file? That is possible, but not supported. The TeX file and the resulting pdf are located in the same directory. Exactly the same pdf is syncing nicely to the TeX file on a client running OS X, but it refuses to do so on the server running OS X Server. Does Skim write errors to a log file, which I can look into? Thanks again! Best, Ivo. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Skim-app-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/skim-app-users
