Take the 2-minute tour ×
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.

Is there a way to have pdfLaTeX emit separate PDF files for each \included file, and somehow massage the \include/\includeonly mechanism so that when using the \includeonly command those files are inserted in the resulting PDF file, but only the \includeonlyed files are actually recompiled?

My main use of the \includeonly mechanism is to speed up compilation when working on part of the document, but it results in the end PDF to not be complete —this is a bit annoying if one needs to refer to things in the excluded parts, for example. A modification of the mechanism as vaporously sketched above would solve this.

share|improve this question
    
This will inevitably result in somewhat broken files —repeated line pages, for example, among the least evil problems— but this is only intended to be used while working on the document... –  Mariano Suárez-Alvarez Jul 11 '12 at 1:50
    
The answer is no. –  egreg Jul 11 '12 at 6:26
add comment

1 Answer

This is not a complete answer, but more an idea on how it might work. It is, however, way to long for a comment.

The idea is to patch the \include command that it internally uses pdfpages to input the parts that are not mentioned in \includeonly from some existing PDF from a previous complete build. Some clever arithmetic might be necessary to calculate the page numbers, but in principle this could work.

A big issue might be hyperrefs. All parts are compiled with the same .aux files, so labels and page anchors should be consistent. However, they are lost when embedding PDFs with \includepdf. Nevertheless, in conjuction with (2) pax it might be possible to fix this. From the pdfpages documentation:

Links and other interactive features of PDF documents When including pages of a PDF only the so called content stream of these pages is copied but no links. Up to now there are no TeX-engines (pdfTeX, XeTeX, ...) available that can copy links or other interactive features of a PDF document, too. Thus, all kinds of links1 will get lost during inclusion. (Using \includepdf, \includegraphics, or other low-level commands.) However, there’s a gleam of hope. Some links may be extracted and later reinserted by a package called pax which can be downloaded from CTAN. Have a look at it!

pax is a combination of a Java tool to extract link information from the PDF you intend to embed and a package that reads in this information to restore the links into embedded PDF. It is still considered as experimental and I have not tried it. However, it is written by Heiko Oberdiek, so I would be optimistic that it works.

To conclude: Given some decent TeX skills, I think that your idea is achievable. However, given the complexity and involved tool chain, I doubt that in the end this is would be a big time saver. If compilation time is the issue, I suggest to consult How can I speed up LaTeX compilation? for other optimization strategies.

share|improve this answer
    
My compilation time is very fast, actually: I am using a custom format and a few other less significant improvements (together with way too much memory and a solid state drive!) But at over a hundred pages, compilation does take noticeable time. \includeonly is useful, for has the annoying effect of producing incomplete files. –  Mariano Suárez-Alvarez Jul 11 '12 at 7:26
    
If I could tell pdflatex to keep processing but not outputting any material to the output file, and then turn back outputting off, I could easily do this, by the way (together with a little Makefile magic, but I am already doing this —for example, the custom format is rebuilt automagically for me when the prologue of the document or any of the ancillary style files, are modified) –  Mariano Suárez-Alvarez Jul 11 '12 at 7:28
    
I imagine simply turning \shipout into a noop during the time output is not wanted will not work... –  Mariano Suárez-Alvarez Jul 11 '12 at 8:06
    
@MarianoSuárez-Alvarez: Now I am a bit confused about your actual goal. Is it to speed up or is it not to speed up? If it is, do you really think that "keep processing, but not outputting material" would significantly speed up? –  Daniel Jul 11 '12 at 8:10
    
No. The idea is to first create a PDF file for each \ìncluded file (and each of these should look exactly the same as it would look if the complete document is processed: it is for this that I'd like to turn off outputting) and then, in the «normal» runs to make \include insert those PDF files instead of simply ignoring them when they are not in the \includeonly list. The only outside help here would be to have something run once per included file to generate the partial PDF files. –  Mariano Suárez-Alvarez Jul 11 '12 at 8:17
show 1 more comment

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.