If your objective is
- to get a standalone PDF output without excessive white spaces
surrounding it, and
- to import the resulting PDF from within your main (La)TeX input file
then the remaining paragraphs might be useful for you.
In this answer, I assume you are a Windows user. If it is not the case, you have to adapt the given MS-DOS batch files (also known as make file in other OS).
WARNING: I also assume that the TeX input file, that is used to
produce the standalone PDF output, does not load animate
package.
Why? Because the animation in the standalone PDF output will NO
LONGER work when it is imported into your main TeX file by using
either \includepdf{}
or \includegraphics{}
.
I will use the following image in this answer, name it hen.jpg
.
I will divide into 2 cases based on whether or not an input file, that is used to produce a standalone PDF output, imports images. If you don't import images in the input file, that is used to produce a standalone PDF output, then the division is not important but you should choose the faster one!
Case 1
This compilation is much much faster than the compilation that will be discussed in Case 2.
However, you cannot use this work flow if your input file imports any image of type PDF, PNG and/or JPG. If you only import EPS images or you don't import any image, you should choose this work flow because the compilation is much much much faster!
Create a batch file, name it DevLa.bat
, to compile an input file that is used to produce a standalone PDF output.
rem It takes an input file name WITHOUT extension.
echo off
del %1.pdf
rem latex %1
latex %1
dvips -D10000 -t unknown %1
gswin32c -r10000 -dCompatibilityLevel=1.5 -dAutoRotatePages=/None -dPDFSETTINGS=/prepress -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=%1.pdf %1.ps
del %1.log
del %1.aux
del %1.dvi
del %1.ps
For simplicity, you can save it in the same directory in which the input file exists. If you want to reuse this batch for other project, then you need to setup PATH environment variable.
The following MWE withoutimage.tex
(which does not import images) can be compiled with DevLa.bat
% withoutimage.tex
\documentclass{article}
\usepackage{pstricks,multido}
\SpecialCoor
\psset
{
linecolor=red,
arrows=->,
arrowscale=1.5 0.75
}
\usepackage[active,tightpage]{preview}
\PreviewBorder=0pt
\PreviewEnvironment{pspicture}
\begin{document}
\begin{pspicture}(-2,-2)(2,2)
\psframe[linecolor=red](-2,-2)(2,2)
\multido{\i=0+30}{12}
{%
\psline(0.9;\i)
\uput{1}[\i]{\i}(0,0){$\i^\circ$}%
}
\end{pspicture}
\end{document}
by invoking
DevLa withoutimage
And you will get a tight PDF output as follows.
Case 2
This compilation is much much slower than the compilation discussed in Case 1. However, you can use this work flow if your input file imports any image of type PDF, PNG, JPG and/or EPS. If you only import EPS images or you don't import any image, you should choose the work flow in Case 1 because its compilation is much much much faster!
Create a batch file, name it DevXe.bat
, to compile an input file that is used to produce a standalone PDF output.
rem It takes an input file name WITHOUT extension.
echo off
del %1.pdf
rem xelatex %1
xelatex %1
del %1.log
del %1.aux
For simplicity, you can save it in the same directory in which the input file exists. If you want to reuse this batch for other project, then you need to setup PATH environment variable.
The following MWE withimage.tex
(which does import a JPG image) can be compiled with DevXe.bat
% withimage.tex
\documentclass{article}
\usepackage{graphicx}
\usepackage{pstricks,multido}
\SpecialCoor
\psset
{
linecolor=red,
arrows=->,
arrowscale=1.5 0.75
}
\usepackage[active,tightpage]{preview}
\PreviewBorder=0pt
\PreviewEnvironment{pspicture}
\begin{document}
\begin{pspicture}(-2,-2)(2,2)
\psframe[linecolor=red](-2,-2)(2,2)
\multido{\i=0+30}{12}
{%
\psline(0.9;\i)
\uput{1}[\i]{\i}(0,0){\includegraphics[scale=0.1]{hen}}% please adapt it!
}
\end{pspicture}
\end{document}
DevXe withimage
And you will get a tight PDF output as follows.
Importing the stadalone PDF outputs
After getting the standalone PDF outputs, you can import them from within your main input file as follows.
% main.tex
\documentclass{article}
\usepackage{graphicx}
\usepackage{lipsum}
\begin{document}
\lipsum[1]
\begin{figure}[hbtp]
\centering
\includegraphics[width=0.75\linewidth]{withoutimage}
\caption{This is a nice image.}
\end{figure}
\lipsum[2]
\begin{figure}[hbtp]
\centering
\includegraphics[scale=1.5]{withimage}
\caption{This is a nice image too.}
\end{figure}
\lipsum[3]
\end{document}
And it can be compiled using either xelatex
or pdflatex
.
If the main.tex
still have other PSTricks codes with labels, then
use xelatex
because pdflatex
with auto-pst-pdf
will break the
labels.
And the result is as follows.
Postscript is still used as an intermediate document format, since it is a fully fledged programming language allowing you to compute graphics, which PDF doesn't. PDF shows just the result (after some conversions, sometimes called "Distillation") of the computation Postscript is able to do.
The Postscript based PSTricks package is an example that heavily makes use of graphical computation. It can even solve differential equations. And if you have a Postscript printer, it can do these computations for you.
EDIT, to answer Daniels comment:
One feature that makes Postscript the preferred format, in particular for a publisher, is its editability. If, for instance, line art in a document is too faint, the publisher may want to enhance it a bit globally before giving the document to press. This very issue was raised, e. g., in this question.
With Postscript, doubling the line width in the whole document is easily accomplished by putting
userdict /setlinewidth {2 mul systemdict /setlinewidth get exec} put
into the document header.
With PDF such a tweak is much more complicated.
Best Answer
I'm not sure of the requirements for reading the info back into TeX, but you can get the bounding box information from ghostscript formatted as a DSC comment.
This will print 2 lines to stderr in response to each
showpage
event.(The extra blank line was when I hit enter for the invisible showpage prompt. Invisible because I redirected stdout to get a nice picture of stderr.)
To capture it in a file, we need to wrangle the stderr handle.
Some other useful options are
-dBATCH
: exit after the file (otherwise it goes to a PS> prompt), and-dNOPAUSE
: do not wait for enter at showpage.If we can control how the shell-out to gs is handled, it might be possible to pipe the postscript fragment without an additional intermediate file.
This assumes the postscript program makes no interfering text output of its own.