On Thu, 2007-06-07 at 09:56 -0400, Richard Heck wrote: > kpdf stores zoom and such between sessions on my machine.
Actually I only tried PS so I should have said kghostview only. > > Maybe keep the one viewer open, overwrite the file, and send it a signal > > to revert? I would have thought that particular idea would be really > > handy with anybody else working with TeX and constantly regenerating the > > same file - maybe a command line switch to cause the viewer to watch for > > changes (or accept SIGUSR1 etc.) and pop to the front at the same page > > num, zoom setting, window location as before. Only launch a new viewer > > if the old process doesn't exist any more. > > > This is already possible in LyX: It's what the "update" stuff on the > view menu does---generate the file (dvi, whatever) but NOT open the > viewer. The viewer then sees the changed file and reloads. Again, kpdf > and kdvi will both do this. And cua.bind has C-S-D for buffer-update dvi > already, too. Confirmed for KPDF, although there is no key binding for it just as there isn't one for PDF. I originally dropped generating DVI because it wouldn't print (xdvi sucks!). Now that I knew to look for KDVI I found it in the online SUSE repository, meaning they left it off the discs. I bet that problem is long gone and I should give it another shot. I remember now that I was probably doing this 4 years ago but forgot :) All we need now is to bring the viewer to the front after doing the update. If we kept track of the viewer process we would know when to delete the temp file or when to invoke the regular non-update version of the command (opening a fresh viewer). Is it possible, knowing the process, to bring the viewer to the front? Question: how is a new user to decide which of the three seemingly identical options to pick for generating a PDF? Are they almost functionally equivalent? Shouldn't one of them be chosen in preference to the others? (perhaps by giving it a keybinding by default, but not the other two) Have fun, Darren
