Re: Frescobaldi external PDF viewer not updating

[David Wright]

On Mon 23 Apr 2018 at 22:30:54 (+1000), Andrew Bernard wrote:
> Hi All,
> 
> I don't think it's case closed yet.
> 
> Although this is referring to pdflatex, it directly references problems
> with Skim and file notifications in the Mac OS kernel.
> 
> https://tex.stackexchange.com/questions/36504/latexmk-pvc-option-breaks-when-compiling-beamer-class/36585#36585
> 
> There may be something similar in our context with ghostscript etc, and
> definitely we don';t know enough about Mac OS internals and files and
> notifications.
> 
> Also, allow me to clarify. When I said I cannot reproduce the problem, I
> went on to say that Preview is erratic. So in fact, I can reproduce the
> problem (apologies for being obtuse!). Preview only updates sometimes after
> a compile - this is what I mean by erratic.

Yes, sorry, I got caught out by "Preview" being the first word of a
sentence (and therefore capitalised) and thought it was part of Skim,
whereas I guess it's part of Frescobaldi, which I can't speak to.

Nor do I have any knowledge of Skim, nor of current Mac filesystems.
However, I looked at the web page reference and the problem as outlined
could be caused by Skim relying on an open file descriptor, whereas
pdflatex could, after an error has occurred, write a new file from
scratch. Skim is now left holding an open file descriptor pointing to
the inode (unix-speak) of a deleted file (ie no directory entry).

The reply adds a new factor which is that the OS is deciding when to
refresh Skim's display, rather than, as in my experience with xpdf,
leaving it up to the user to do. It sounds as if some OS notifications
happen to arrive at inopportune moments.

However, I'm not aware that Frescobaldi uses pdflatex to write its PDF
files, but was under the impression that they were generated by being
converted from a complete and discrete PostScript file¹. OTOH, the web
page reply might be relevant to people using things like lilypond-book
and \begin{lilypond} with LaTeX documents.

> It would be interesting to get to the bottom of this matte, but I fear we
> are dealing with deep internals issues here, in remote regions normally
> untrodden by mortals - the Mac OS kernel.

I don't understand why the kernel should be involved. I see it as a
userspace problem and the way the applications have been written.

> Skim works for me, but there seems to be something related to large files.
> I am trying one line scores, but Kieren I would imagine you have very large
> orchestral scores. This could be part of the plot, with file writes we
> don't fully have a handle on.

It does sound as if Skim has a very different approach to updating
from my choice of viewer. Xpdf only rereads the file and updates the
display when you (a) change page number, (b) rescale the page,
(c) change the window size, or (d) type r. In particular, it doesn't
update when you expose its window by switching viewports or closing a
window that was concealing it.

This makes it possible to compare two generations of a score by
leaving the old version in one xpdf, running LP, and updating the
version in another xpdf: the blink comparator method², something
that's impossible with a viewer that updates itself, and a feature
I use a lot myself.

¹lilypond -dno-delete-intermediate-files   will leave it around.
²used in the discovery of Pluto.

Cheers,
David.