Tell me more ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.
up vote 3 down vote favorite

I'm having a problem, which breaks my workflow (as I'm working on a very large document, where a full latexmk run may take 10 minutes and even compiling the chapters I'm currently working on with includeonly takes one to several minutes) and I hope someone can help (maybe has seen similar things happening):

I'm working on MacOS X 10.6.8 with TeXLive2011 and with TeXShop 2.43 as editor.

Under certain conditions, I'll see a pdf preview with white pages and only the green hyperref-rectangles as long as the document is compiled with pdflatex. It looks like that: screenshot empty pdf

  • This only seems to happen, when at least the chapters 3 and 4 of my (large) document are included. EDIT: this might be, because those chapters contain many bitmap graphics which increase file size.
  • Some pages of the pdf (e. g. the titlepage) seem to be displayed correctly all the time.
  • If only one of them is included, I can see and browse a preview of the (old) pdf all the time during compile.
  • the same thing happens in Skim.app when I open the pdf there and then compile.

remark: As soon as compiling is finished, the pdf seems to be ok!!

EDIT: to answer the questions in the comments I'll add more information.

  1. this display problem is only existent during compiling time, as soon as the pdf is ready, it is displayed correctly.
  2. However it is not always the case, some documents are always visible - also during compilation.

So jonalv's idea might be the solution: the pdf viewer does not keep the whole file in memory and therefore is not able to display the other pages. As it works for some files, and for others it doesn't, maybe it is a file size issue...

At the moment I'm testing to isolate the problem.

  • a sample document with my whole preamble but with nearly 300 pages of (only) blindtext and one float in it is visible all the time (PDF size 881 kB).
share|improve this question
2  
I can think to a system font cache issue. – egreg Jan 8 '12 at 23:33
1  
Did pdflatex succeed in compiling your document or did it suffer any errors? – Sharpie Jan 8 '12 at 23:40
@Sharpie there are some warnings during compile, but at the end there is a readable pdf and at least the word "error" is not existent in the .log-file (or what should I search for)? – Martin Jan 8 '12 at 23:41
5  
So this is only during the actual compile time? If so, isn't it reasonable that the pdf-viewer does not keep the entire pdf file in memory but reads from it as needed? And when you recompiles the file the pdf is not gonna be there (it's being rebuilt) so what is the pdf viewer to do? Or have I misunderstood your question? – jonalv Jan 16 '12 at 17:12
1  
It is also possible that it depends on compilation speed. The pdf viewer probably only monitors the file for changes at certain intervals, and this behavior only occurs when the viewer happens to try to update the view while the file is being compiled. – Jan Hlavacek Jan 16 '12 at 19:05
show 2 more comments

3 Answers

up vote 9 down vote accepted
+50

As Michael has already pointed out it is not reasonable to expect that the viewing of a volatile file (as being built) is always correct.

Nevertheless it sometimes does work and sometimes does not work and the OP wants to know the reason behind. The following is an explanation of the technicalities in the background:

The problem is related to the way pdflatex works and how file notifications are implemented in OSX (and its Mach kernel under the hood), which are used by most PDF viewers to update the view "on change".

  • pdflatex does not write the PDF file in an atomic manner, but during the compilation process more or less continuously adds bits and bytes to it.

  • The file system notices the writes to the file and sends an update notification to the monitoring PDF viewer process. It uses some heuristics to not send an update event for every single changed byte (which would be very inefficient). The common approach here is to delay the update notification until no new changes have shown up for some time (usually a couple of milliseconds).

  • If this heuristic interacts badly with the write pattern of pdflatex, the PDF viewer gets notified before the PDF is ready and tries to read a not-yet complete PDF file.

  • The problem is not bound to specific documents or document classes. However, I personally observed it especially in conjunction with larger beamer presentations and with my thesis. My assumption is that when compiling "big" documents (that require a lot of computation or generate a lot of auxiliary files), pdflatexs updates to the PDF file during compilation are less frequent, which increases the probability of a bad interaction with the file system's heuristic to send change notifiations.

PDF viewer react differently when reading an incomplete PDF file. Skim, for instance, tends to crash or to loose the notification handle to the file system, so that no further updates show up. Apparently, TexShop's internal PDF viewer is more robust against this kind of problems.

share|improve this answer
thank your for this explanation and thank you very much for taking my question seriously! – Martin Jan 17 '12 at 9:50
1  
pdflatex does not change the PDF, it rewrites it completely. – Martin Schröder Jan 18 '12 at 7:28
@MartinSchröder: Thanks, I have clarified this in the answer. – Daniel Jan 18 '12 at 8:25
up vote 6 down vote

It is not reasonable to expect that you can view the file while as it is being built. There is no particular "problem" or "issue" here.

share|improve this answer
However, there are many cases when it works - so I'd like to know the reason. So may you explain why I can't expect it? Is it because the PDF viewer will/can not keep the whole file in its memory (and therefore with small files, which are kept completely in RAM, it works)? For a file which compiles quickly, this may be unimportant, but in my case a full latexmk run may take 10 minutes and IMHO it is very inconvenient for the workflow if I can not continue reading and editing the pdf during this time. – Martin Jan 17 '12 at 9:11
You can't expect to view the file because it doesn't exist yet. Jonalv's answer proposes a way to make sure that you can view the previous version, but I wonder how useful that may be - I usually want to see the most recent one. I'm wondering why it would take 10 minutes to build your file? My recently finished book has 400 pages and > 200 figures and takes about half a minute to build, with index and all. The figures are built separately and simply included as PDF via \includegraphics. Do you have a lot of graphics material included as Latex code that gets compiled during each run? – Michael Palmer Jan 17 '12 at 15:14
up vote 3 down vote

I understand the question as: "How can I keep browsing my pdf at the same time as LaTeX is rebuilding it?". Maybe we can use some buffering here. If you compile using a command that moves the pdf once it is done there will be almost no time when you can not view the file. Something like: (for Mac)

latexmk -pdf text.tex && mv text.pdf viewMe.pdf

If you then set your pdf viewer to watch viewMe.pdf I hope it will update correctly once the file is rebuilt, still allowing you to browse the pdf in the meantime since the actual file only changes when it is actually rebuilt.

share|improve this answer
2  
If the file is large, the copying might also take a long time. Maybe renaming (mv), doing only directory updates, would be a better option. – celtschk Jan 17 '12 at 13:46
Good point, moving is faster than copying. Changing in the answer... – jonalv Jan 17 '12 at 14:18
@jonalv: Thank you very much for posing the question that arises from my problem. I've asked the question which matches your answer, however there is one more thing to take into account (synctex): tex.stackexchange.com/questions/41378/… – Martin Jan 17 '12 at 15:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.