[clue-tech] Great New Adobe Acrobat Version

[Keith Hellman]

On Fri, Mar 25, 2005 at 10:06:43AM -0700, David Anselmi wrote:
> Keith Hellman wrote:
> [...]
> >What *I* would really like acroread to do is:
> >- support b for 'blank' in fullscreen mode (defacto standard from ppt and
> >  impress)
> >- detect when a PDF has changed on disk and reload it (a critical
> >  feature when preparing presentations or papers using LaTeX/Tex).
> 
> I've been using gv to look at html2ps output before I print it.  If I 
> change the ps I have to tell gv to reload it (there's a button for that, 
> at least).  Hmm... it also has a menu option "watch file" that looks 
> like it does what you want.

Yes, I have watch file turned on by default.  Both xdvi and gv watch
(as best I can tell) file timestamps to determine if they need to reload
the file.  My impression is that they (or at least xdvi IIRC) wait for
some type of graphic event (InputEvent, RaisedWindow, UnobsureEvent, ...)
to actually check the timestamp.  This way it doesn't do dumb polling
but also tends to update the display when the user wants it.
 
> No, that doesn't help you at all.  I was just wondering how you'd 
> implement watching the file--polling for changes seems ugly, and you'd 
> not want to get stuck with FAM or something.
> 
> I think full screen mode isn't too hard in X.  Any idea how hard 
> watching a file is?
Yes, I would think full screen should be trivial but it is simply not
something gv or xdvi have a mind to do, and I don't think they should
actually. Both gv and xdvi fulfill the role of typeset *reviewing*
software, whether you see the output in a window or fullscreen, the
*layout* should be the same and that is enough to guide editting.

It is actually a *very small* itch, that is, my desire to have one app
that would do all of this for ps/pdf output, for the most part.  I
would, however, be SOL if acroread pulled fullscreen support... 

(Hmph, it looks like display(1) can also show PDFs, but i lacks the
Next, Prev, 'b' event handling).

-- 
Keith Hellman                             #include <disclaimer.h>
khellman at mcprogramming.com                from disclaimer import standard
public key @ www.mcprogramming.com

"In any project that is multi-threaded, most bugs will come from threading
issues.  This is regardless of programming language -- it's a deep, as yet
ununderstood property of threads."

-- Guido van Rossum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://cluedenver.org/pipermail/clue-tech/attachments/20050325/2a765eb7/attachment.bin