The problem seems to be solved by version 1.1b:
\documentclass{article}
\usepackage{standalone}
\standaloneconfig{mode=buildnew}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{filecontents}
\begin{filecontents*}{Documents/test_standalone_slave.tex}
\documentclass{standalone}
\usepackage{tikz,pgfplots}
\pgfplotsset{compat=newest}
\begin{document}
\begin{tikzpicture}
\draw (0,0) circle (2);
\end{tikzpicture}
\end{document}
\endinput
\end{filecontents*}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{tikz,pgfplots}
\pgfplotsset{compat=newest}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
That's it!
\includestandalone{Documents/test_standalone_slave}
\end{document}
The only issue that still appears to me is while using an external style sheet by using \input{macros.tex}
in the slave's preamble.
If I run pdfinfo -box
on a PDF file generated by pdftex
, I get the following information:
Creator: TeX
Producer: pdfTeX-1.40.15
CreationDate: Mon Oct 6 16:01:48 2014
ModDate: Mon Oct 6 16:01:48 2014
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 595.276 x 841.89 pts (A4) (rotated 0 degrees)
MediaBox: 0.00 0.00 595.28 841.89
CropBox: 0.00 0.00 595.28 841.89
BleedBox: 0.00 0.00 595.28 841.89
TrimBox: 0.00 0.00 595.28 841.89
ArtBox: 0.00 0.00 595.28 841.89
File size: 58874 bytes
Optimized: no
PDF version: 1.5
When I check a PDF exported from TextEdit, I get
Title: ***
Subject:
Keywords:
Author: ***
Creator: TextEdit
Producer: Mac OS X 10.9.2 Quartz PDFContext
CreationDate: Mon Oct 6 14:10:45 2014
ModDate: Mon Oct 6 14:10:45 2014
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 595 x 842 pts (A4) (rotated 0 degrees)
MediaBox: 0.00 0.00 595.00 842.00
CropBox: 0.00 0.00 595.00 842.00
BleedBox: 0.00 0.00 595.00 842.00
TrimBox: 0.00 0.00 595.00 842.00
ArtBox: 0.00 0.00 595.00 842.00
File size: 16393 bytes
Optimized: no
PDF version: 1.3
The only possible problem might be the page width, which is 595.276 in the former case, 595 in the latter.
Now \pdfpagewidth
is set to 597.50787pt
, which corresponds to 595.27559bp
and this explains the shown value of 595.276
. If we convert this into millimeters, we get
597.50787*25.4/72.27 = 209.99999
but converting 595.276bp
to millimeters gives
595.276*25.4/72 = 210.00014
I don't think that a surplus of less than 150nm (nanometers) should trigger a size reduction of 6% “to fit”. Even if 595.28 is used, we have
595.28*25.4/72 = 210.00156
but, again, a surplus of less than 2µm (micrometers) doesn't seem sufficient for pushing Adobe Reader into thinking that the page “doesn't fit”.
The conversion of 595bp
into millimeters is
595*25.4/72 = 209.90278
which is short of 210mm by sligthly more than 0.04%, while 210.00156mm is about 0.001% more than 210mm.
Nothing will convince me that the computations made by Adobe Reader are so accurate that a difference of less than 0.001% forces shrinking.
Best Answer
Deleting (or commenting out) any blank lines between the material and
\end{document}
solves the problem: