PDF-Files in use when the User has opend the PDF-File
Louis Vosloo
> "Jo Schartmueller" <sch...@yahoo.com> wrote:
>
> >When a user has opened a PDF-File it's not possible to replace this file
> >e.g. the distiller has createt a new version.
>
> Yes.
>
> >Why does the Distiller lock this file the time until the user close the
> >reader.
>
> Distiller doesn't lock the file, but Reader does.
>
> >Any ideas about this ??
>
> This is a good idea, because otherwise the file contents would be
> replaced. Reader relies on the contents not changing, and could crash
> if the contents change. It is therefore smart to lock out changing.
Well, actually I think it is *not* a good idea --- from the point of view of
user
convenience. I is a giant pain to have to close the file in Acrobat Reader
ervery time when creating a new version (*). Not to say that it is easy to
avoid this.
But, we have solved a similar problem in our TeX System. The "DVI viewer"
presents a DVI file, but then one typically wants to "re-TeX" (compile)
a new version based on seeing what typos there are etc. It would be
quite unacceptable to TeX users if one had to go to the "DVI viewer"
to first close the DVI file before "re-TeX"ing it!
The new version is displayed when TeX gets through creating it.
And the same page is shown at the same scale and position
(unless the recompilation eliminated this page, in which case the
last page before it appears).
Obviously Adobe hasn't figured out how to do this sort of thing reliably.
Some MS editors have the same disease (MS Word e.g.) while some
others do not (NotePad e.g.)
(*) Other examples of lack in good interface in Acrobat is the lack
of a MRU list in Distiller. Don't people ever edit PS files, then
distill, view the result, then re-edit the PS file and have to re-distill?
--
http://www.yandy.com/unique.htm
Aandi Inston
>Some MS editors have the same disease (MS Word e.g.) while some
>others do not (NotePad e.g.)
File locking isn't a disease. Rather, I see it as something that Unix
people wilfully ignore, rather than doing right...
----------------------------------------
Aandi Inston qu...@dial.pipex.com http://www.quite.com
Please support usenet! Post replies and follow-ups, don't e-mail them.
MicroPress, Inc.
wrote:
>Aandi Inston wrote:
>
>> "Jo Schartmueller" <sch...@yahoo.com> wrote:
>>
>> >When a user has opened a PDF-File it's not possible to replace this file
>> >e.g. the distiller has createt a new version.
>>
>> Yes.
>>
>> >Why does the Distiller lock this file the time until the user close the
>> >reader.
>>
>> Distiller doesn't lock the file, but Reader does.
>>
>> >Any ideas about this ??
>>
>> This is a good idea, because otherwise the file contents would be
>> replaced. Reader relies on the contents not changing, and could crash
>> if the contents change. It is therefore smart to lock out changing.
>
>Well, actually I think it is *not* a good idea --- from the point of view of
>user
>convenience. I is a giant pain to have to close the file in Acrobat Reader
>ervery time when creating a new version (*). Not to say that it is easy to
>avoid this.
>
>But, we have solved a similar problem in our TeX System. The "DVI viewer"
>presents a DVI file, but then one typically wants to "re-TeX" (compile)
>a new version based on seeing what typos there are etc. It would be
>quite unacceptable to TeX users if one had to go to the "DVI viewer"
>to first close the DVI file before "re-TeX"ing it!
There is a big difference between solving any kind of problem when
you control both ends of the process (Dvi writing & Dvi reading); and
when you do not (Acrobat Reader); this is why most (all?) Dvi
previewers allow to re-TeX & refresh.
With PDF it is trickier. One solution is XPDF (which does not exist on
Windows); the other is VTeX (Windows, any version of Acrobat); our
IDE allows to recompile a document which is previewed and makes
the Acrobat automatically refresh.
>
>Obviously Adobe hasn't figured out how to do this sort of thing reliably.
There is nothing sophisticated in doing this sort of thing _in your
own program_; Adobe simply did not provide the feature.
>
>Some MS editors have the same disease (MS Word e.g.) while some
>others do not (NotePad e.g.)
Notepad keeps very small and purely text files fully in memory; MS
Word operates with potentially huge disk-based files; this is not
exactly a meaningful comparison.
Giuseppe Bilotta
> Aandi Inston wrote:
>
> > "Jo Schartmueller" <sch...@yahoo.com> wrote:
> >
> > >When a user has opened a PDF-File it's not possible to replace this file
> > >e.g. the distiller has createt a new version.
> >
> > Yes.
> >
> > >Why does the Distiller lock this file the time until the user close the
> > >reader.
> >
> > Distiller doesn't lock the file, but Reader does.
> >
> > >Any ideas about this ??
> >
> > This is a good idea, because otherwise the file contents would be
> > replaced. Reader relies on the contents not changing, and could crash
> > if the contents change. It is therefore smart to lock out changing.
>
> Well, actually I think it is *not* a good idea --- from the point of view of
> user
> convenience. I is a giant pain to have to close the file in Acrobat Reader
> ervery time when creating a new version (*). Not to say that it is easy to
> avoid this.
GhostScript + GSView.
--
Giuseppe "Oblomov" Bilotta
Axiom I of the Giuseppe Bilotta
theory of IT:
Anything is better than MS
Giuseppe Bilotta
> Louis Vosloo <sup...@YandY.com> wrote:
>
> >Some MS editors have the same disease (MS Word e.g.) while some
> >others do not (NotePad e.g.)
>
> File locking isn't a disease. Rather, I see it as something that Unix
> people wilfully ignore, rather than doing right...
"Right" or "Wrong" is relative.
MS philosophy assumes the user knows not what he is doing.
Unix philosophy assumes the user *knows* what he is doing.
The best thing is a compromise where a program can be set to a choice
of (1) ignore changes [memory expensive] (2) warn if changed (3)
reread on change.
Louis Vosloo
> Louis Vosloo <sup...@YandY.com> wrote:
>
> >Some MS editors have the same disease (MS Word e.g.) while some
> >others do not (NotePad e.g.)
>
> File locking isn't a disease. Rather, I see it as something that Unix
> people wilfully ignore, rather than doing right...
When a process is not active, there is no need for it to keep
the file open (and it is anti-social for it to do so).
All it is doing is passively showing on screen what it derived
when last looking at the file.
When it becomes active, it can check whether the file has changed
and decide whether it needs to recompute what it is showing on screen.
There is no fundamental reason that Acrobat Reader should keep
a PDF file open (again, I am not saying it is *trivial* to get it right,
just that it is logical, convenient for the user, and can be done).
And the way our system handles DVI files is an existence proof,
since we have *exactly* the same issues: there is (i) a "viewer"
that reads DVI files, and there is (ii) a "compiler" that creates new
versions of the DVI files. Replace "DVI" with "PDF", "DVI viewer"
with "PDF viewer", and "TeX" engine with "Distiller".
So I maintain: file locking *is* a disease (using your terminology :-).
--
http://www.YandY.com/unique.htm
Aandi Inston
>Aandi Inston wrote:
>
>> Louis Vosloo <sup...@YandY.com> wrote:
>>
>> >Some MS editors have the same disease (MS Word e.g.) while some
>> >others do not (NotePad e.g.)
>>
>> File locking isn't a disease. Rather, I see it as something that Unix
>> people wilfully ignore, rather than doing right...
>
>When a process is not active, there is no need for it to keep
>the file open (and it is anti-social for it to do so).
>All it is doing is passively showing on screen what it derived
>when last looking at the file.
I disagree. That would be the case if the file had been completely
read into memory or otherwise processed. Processes like Acrobat read
on demand, so it is important that the file be unaltered. They are
locking for that specific reason.
>
>When it becomes active, it can check whether the file has changed
>and decide whether it needs to recompute what it is showing on screen.
It could.
>There is no fundamental reason that Acrobat Reader should keep
>a PDF file open (again, I am not saying it is *trivial* to get it right,
>just that it is logical, convenient for the user, and can be done).
But then what does it say to the user. How does it reposition if the
user was reading the file? What if they were filling a form? It is not
obvious that there is a good solution.
noy...@socrates.berkeley.edu
Aandi Inston writes:
(apologies in advance if I'm getting my attributions mixed up)
>I disagree. That would be the case if the file had been completely
>read into memory or otherwise processed. Processes like Acrobat read
>on demand, so it is important that the file be unaltered. They are
>locking for that specific reason.
Horsefeathers. Acrobat reader for Solaris and for Linux do not lock
the file they are reading.
Aandi Inston
noy...@socrates.berkeley.edu
Aandi Inston writes:
> Ah, a bug! I wonder if Adobe will fix it.
Any sufficiently advanced bug is indistinguishable from a feature.
Jesper Harder
> >I is a giant pain to have to close the file in Acrobat Reader ervery
> >time when creating a new version (*). Not to say that it is easy to
> >avoid this.
>
> With PDF it is trickier. One solution is XPDF (which does not exist on
> Windows); the other is VTeX (Windows, any version of Acrobat); our
> IDE allows to recompile a document which is previewed and makes
> the Acrobat automatically refresh.
On Windows you can also use Acroreads DDE-interface to close the
document in Acrobat before recompiling. With Emacs/AUCTeX it's quite
simple to do it automatically.
Christian Schlauer
> On Windows you can also use Acroreads DDE-interface to close the
> document in Acrobat before recompiling. With Emacs/AUCTeX it's quite
> simple to do it automatically.
Could you please post some more information about that?
--
Christian Schlauer
Jesper Harder
Acrobat supports a number of DDE-commands (described in »Acrobat
Interapplication Communication Reference«), which makes it possible for
other applications to tell Acrobat to open documents, close documents and
so on.
We want to use the command 'CloseAllDocs()', which closes all open
documents in Acrobat.
Here's a piece of code which defines a new AUCTeX command, PDFLaTeX,
that closes documents in Acrobat before compiling the LaTeX source. To
use it you should put it in tex-site.el:
(defun acrobat-close-all-docs ()
"Close all open documents in Acrobat."
(save-excursion
(set-buffer (get-buffer-create " *ddeclient*"))
(erase-buffer)
(insert "[CloseAllDocs()]")
(call-process-region (point-min) (point-max)
"ddeclient" t t nil "acroview" "control")
(if (= 0 (string-to-int (buffer-string))) t nil)))
(defun TeX-run-pdfLaTeX (name command file)
"Create a process for NAME using COMMAND to format FILE with pdfLaTeX."
(acrobat-close-all-docs)
(TeX-run-LaTeX name command file))
(add-to-list 'TeX-command-list
(list "PDFLaTeX" "pdflatex \\nonstopmode\\input{%t}" 'TeX-run-pdfLaTeX nil t))
Christian Schlauer
> Acrobat supports a number of DDE-commands (described in »Acrobat
> Interapplication Communication Reference«), which makes it possible for
> other applications to tell Acrobat to open documents, close documents and
> so on.
>
> We want to use the command 'CloseAllDocs()', which closes all open
> documents in Acrobat.
>
> Here's a piece of code which defines a new AUCTeX command, PDFLaTeX,
> that closes documents in Acrobat before compiling the LaTeX source. To
> use it you should put it in tex-site.el:
[Emacs-Lisp snipped]
Shouldn't that become part of AUC TeX? As it is Windows-specific, it
should probably go into tex-mik.el, which is the file where the
command list for MikTeX users is defined (`View' calls Yap, and so
on). Why don't you post it on news://sunsite.dk/emacs.auc-tex?
--
Christian Schlauer
Jesper Harder
> Jesper Harder <har...@myrealbox.com> writes:
>
>> Here's a piece of code which defines a new AUCTeX command, PDFLaTeX,
>> that closes documents in Acrobat before compiling the LaTeX source. To
>> use it you should put it in tex-site.el:
>
> [Emacs-Lisp snipped]
>
> Shouldn't that become part of AUC TeX?
I'm not sure that it's the right solution for everyone. I don't think
that people who use gsview to view PDF files will be particularly happy
about having all open documents i Acrobat closed when they invoke
PDFTeX.
Using 'CloseAllDocs()' is just a quick hack. It *is* possible to close
just one document, but only if the document was opened with DDE. That's
a bit more tricky, because AUCTeX expects to invoke an external command
to view files.
> Why don't you post it on news://sunsite.dk/emacs.auc-tex?
I'm already subscribed. Maybe we should continue the discussion there?
Christian Schlauer
> I'm not sure that it's the right solution for everyone. I don't think
> that people who use gsview to view PDF files will be particularly happy
> about having all open documents i Acrobat closed when they invoke
> PDFTeX.
Yes. `CloseAllDocs' is not perfect.
> Using 'CloseAllDocs()' is just a quick hack. It *is* possible to close
> just one document, but only if the document was opened with DDE. That's
> a bit more tricky, because AUCTeX expects to invoke an external command
> to view files.
>
> > Why don't you post it on news://sunsite.dk/emacs.auc-tex?
>
> I'm already subscribed. Maybe we should continue the discussion there?
Yes.
--
Christian Schlauer