Reload PDF files (and therefore no locking) possible?

rc-flitzer · Post by **rc-flitzer** » Mon Jul 02, 2007 3:02 pm

Hello!
I'd like to suggest a feature that is not to find in any PDF viewer running on Windows. So it would be great if PDF-XChange can be the first.

The problem is following, first I will describe a concrete situation. For writing texts I'm using LaTeX, hoping you know it. If not: it's a type setting system where you simply write text and control commands in a simple text file. In a second step you kind of "compile" the text and get the PDF to look at.

Now when I compile my LaTeX file and create a PDF, then start PDF-XChange to watch it. Maybe there will be a mistake in text, so I fix it and recompile it. And here's the problem: I can't recompile the PDF when it is still opened in PDF-Viewer because the file is locked. My workaround is to close the file, compile, reopen it and browse to the former page (as long as there's no history in PDF-XChange).

The question is from a technical view: why do you have to lock the PDF? From a technical view it is not necassary. On Linux (evince, xpdf) or MacOS (internal PDF viewer) it's possible to change the PDF while it is open. The viewer can recognize the change date and automatically reload it (or offer a reload button).
You can compare with a text file editor: it allows to view and to change the file but I still can change it with any other program. The editor recognizes changes and asks me to reload or to keep my changes and save it (e.g. as another filename).

It would be great to add this feature in PDF-XChange Viewer.

rc-flitzer · Post by **rc-flitzer** » Mon Jul 23, 2007 10:20 am

At least a confirmation of reading the posting above would be polite. Some comments would be even better.

If someone did not quite understand what my concerns are, please feel free to ask.

Mon Jul 23, 2007 10:48 am

Text editors can afford it, because they operate with not so large amount of datas. But PDF viewer never hold complete PDF (all the more in its original format) into the memory.
And the feature you propose, will require to create temporary copy of the file the viewer had open, and works with this temp file, but not with original one.
And there are a lot of questions what to do in different situations:
1. original file was deleted
2. original file was replaced with bad PDF or not a PDF file (say image)

rc-flitzer · Post by **rc-flitzer** » Wed Jul 25, 2007 5:58 pm

Point for you. I understand the problem and the reasoning, but it seems to me somehow like an excuse. There are indeed PDF reader applications which support this feature, I mentioned some above. And they are not slow in reading or starting (as you mentioned the temporary file to be created first).

The example problems named here could be solved easily:
1. the current page can still be displayed but the application says "hey, there's no file anymore - save current page?"
2. that's not so nice but you still could show the current page, which is more than you'd have when closing -> changing PDF -> reopening (leads to error).

And so on ... other PDF reader don't have this problem (except Adobe Reader). xpdf, MacOS tools or any DVI viewer on windows.

A question about creating temporary file: what about the editing features? Surely changes in PDF file have to be stored in some temporary file or in memory because I can close PDF without all changes saved permanently. This contradicts somehow your explanation...