Looking at a PDF/DVI while it is being produced
Hi, sometimes on a long run one would like to be able to take a look at the current state of a PDF being produced. I don't know whether there is something like a progressive PDF format: likely not. But if I could send a signal to my PDFTeX/LuaTeX process, and this would cause it (at least if it would not currently be in a \shipout) to flush the current buffers, create a copy of the current PDF/DVI file under a snapshot name, properly finish/close it (writing reference table/DVI trailers) and then resume regular work, this would be quite dandy. I often have the situation of starting a dead slow 1400 page compilation where I really need the full output, but can probably see after looking at a dozen pages whether or not the whole compilation will be rubbish, needs some minor change and restart. Being able to use a signal for "give me a viewable snapshot PDF/DVI for the current state of the document" would be rather invaluable. It would be conceivable to offer this as an option to the TeX interactive prompt, by typing
mysnap.pdf
Then one could just interrupt PDFTeX using ^C as usual, and type this command for getting a snapshot. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
Hi, David Kastrup wrote:
Hi, sometimes on a long run one would like to be able to take a look at the current state of a PDF being produced.
I don't know whether there is something like a progressive PDF format: likely not.
I doubt it would be possible to do, that even with changes to pdftex. In any case you end up with either no embedded fonts at all, or a rather massive PDF with each page having its own font subsets and images.
But if I could send a signal to my PDFTeX/LuaTeX process, and this would cause it (at least if it would not currently be in a \shipout) to flush the current buffers, create a copy of the current PDF/DVI file under a snapshot name, properly finish/close it (writing reference table/DVI trailers) and then resume regular work, this would be quite dandy.
The idea is interesting, but I have absolutely no time to implement it. I fear that getting the details right may take quite some time (forking is easy, the tricky bit is duplicating the open files and file handles).
I often have the situation of starting a dead slow 1400 page compilation where I really need the full output, but can probably see after looking at a dozen pages whether or not the whole compilation will be rubbish, needs some minor change and restart.
Can't you just interrupt tex always and at the error prompt "I\end" ? If the PDF turns out to be OK after all, you will have to generate 1414 or so pages, a 10% overhead, not that bad compared to generating 2800. Best wishes, Taco
On Sat, Mar 08, 2008 at 09:54:16AM +0100, Taco Hoekwater wrote:
David Kastrup wrote:
Hi, sometimes on a long run one would like to be able to take a look at the current state of a PDF being produced.
I don't know whether there is something like a progressive PDF format: likely not.
I doubt it would be possible to do, that even with changes to pdftex. In any case you end up with either no embedded fonts at all, or a rather massive PDF with each page having its own font subsets and images.
It would be possible using incremental updates (PDF spec: `3.4.5 Incremental Updates'). Each page would add an update section. It avoids PDFs having own fonts and images for each page. Nothing needs to be embedded, if the character or image is already embedded on the previous pages. But if a character of an already embedded font is missing, then the font with a larger subset needs embedding again.
But if I could send a signal to my PDFTeX/LuaTeX process, and this would cause it (at least if it would not currently be in a \shipout) to flush the current buffers, create a copy of the current PDF/DVI file under a snapshot name, properly finish/close it (writing reference table/DVI trailers) and then resume regular work, this would be quite dandy.
The idea is interesting, but I have absolutely no time to implement it. I fear that getting the details right may take quite some time (forking is easy, the tricky bit is duplicating the open files and file handles).
Duplicating open files/file handles is not necessary. It would
need a procedure that copies the PDF file so far to a new file and
finishing the new file without changing the internal states of pdfTeX.
But I agree both methods would cost lots of time.
Yours sincerely
Heiko
Taco Hoekwater
David Kastrup wrote:
But if I could send a signal to my PDFTeX/LuaTeX process, and this would cause it (at least if it would not currently be in a \shipout) to flush the current buffers, create a copy of the current PDF/DVI file under a snapshot name, properly finish/close it (writing reference table/DVI trailers) and then resume regular work, this would be quite dandy.
The idea is interesting, but I have absolutely no time to implement it. I fear that getting the details right may take quite some time (forking is easy, the tricky bit is duplicating the open files and file handles).
Most of the file handles would likely be best served by just closing them (in order not to mess up the output of the continuing process).
I often have the situation of starting a dead slow 1400 page compilation where I really need the full output, but can probably see after looking at a dozen pages whether or not the whole compilation will be rubbish, needs some minor change and restart.
Can't you just interrupt tex always and at the error prompt "I\end" ? If the PDF turns out to be OK after all, you will have to generate 1414 or so pages, a 10% overhead, not that bad compared to generating 2800.
Well, actually the workflow is to trigger a snapshot, peruse it to its end, trigger another snapshot, and so on. The first runs will probably be bad on the first dozen pages, but later runs might get increasingly further before a problem requiring a fix and rerun crops up. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum
2008/3/8, Taco Hoekwater
I doubt it would be possible to do, that even with changes to pdftex. In any case you end up with either no embedded fonts at all, or a rather massive PDF with each page having its own font subsets and images.
pdfTeX would have to generate incremental PDF (3.4.5), and the changes would be non-trivial (fonts, images, page tree, objects, ...), while the benefits are probably of interest for only a small number of users (as the normal user doesn't have such large documents).
But if I could send a signal to my PDFTeX/LuaTeX process, and this would cause it (at least if it would not currently be in a \shipout) to flush the current buffers, create a copy of the current PDF/DVI file under a snapshot name, properly finish/close it (writing reference table/DVI trailers) and then resume regular work, this would be quite dandy.
The idea is interesting, but I have absolutely no time to implement it. I fear that getting the details right may take quite some time (forking is easy, the tricky bit is duplicating the open files and file handles).
Yes, forking would be a way. But I would not implement it in pdfTeX anymore. Definitely luaTeX. Best Martin
participants (4)
-
David Kastrup -
Heiko Oberdiek -
Martin Schröder -
Taco Hoekwater