Showing posts with label graphics. Show all posts
Showing posts with label graphics. Show all posts

Thursday, June 12, 2008

LaTeX generated figures: Using preview instead of pst-eps

I've been using the pst-eps package when I want to generate EPS versions of coded graphics (e.g., graphics produced with PSTricks or the standard picture environment). From the pst-eps description:
Pst-eps is a PSTricks (pstricks)-based package for exporting PSTricks images ‘on the fly’ to encapsulated PostScript (EPS) image files, which can then be read into a document in the usual way.
By wrapping lines in a TeXtoEPS environment, you setup LaTeX to produce an image of the enclosed content with a tight bounding box. It works well, but you must use dvips -E to generate your EPS files with the proper bounding box. If you want to then generate a PDF, you have to use something like epstopdf (possibly with the EPSCrop GhostScript option) to do it. Additionally, there's a lot of overhead within the actual TeX source. In other words, it's not quite easy to use.

A BETTER OPTION: Today, I discovered the preview package, which is described with:
The package is a free-standing part of the preview-latex bundle. The package provides the support preview-latex needs, when it chooses the matter it will preview. The output may reasonably be expected to have other uses, as in html translators, etc.
This package appears to be a much nicer solution. You can use standard latex or pdflatex to compile. If you need to use latex but still want EPS or PDF outputs, you can use dvips and ps2pdf without any special options. Otherwise, the introduced preview environment works very similar to the old TeXtoEPS environment, but it requires less work to use and seems to apply to a broader class of content.

Here's an example that should not require anything fancy to build. If you don't have the amsmath package (you should), you can omit it and get rid of the gather* environment:
\documentclass{article} 
\usepackage{amsmath} % for gather*
\usepackage[active, % Turns previewing on
tightpage, % Squeezes pages around previews
textmath, % Subjects textual math to a preview
displaymath, % Subjects math displays to preview
floats % Subjects floats to preview
]{preview}
% There is a ``graphics'' option too that subjects
% includegraphics to preview. If they are already in a
% float, the ``floats'' option is sufficient.
\begin{document}

This text will NOT get printed.

\begin{equation}
a = b
\end{equation}

The math following the colon gets printed: $x = 5$?

\begin{gather*}
c = d
\end{gather*}

More text not printed.

\begin{preview}
Page 2 is here (with tight border).
\end{preview}

You'll never see this text.

\begin{figure}
\fbox{\fbox{\fbox{A figure that is printed}}}
\end{figure}

\end{document}
If the active option of preview is commented out, the file builds as if preview didn't exist. However, with it turned on, only the sections in preview environments get printed, and they each get put on a separate page with tight borders. Options like displaymath, textmath, and floats cause those types of content to get automatically wrapped with a preview environment.

Related posts:

Tuesday, September 18, 2007

Ted E.C.E. Bear

I put this together for my ECE webpage.
Ted E.C.E. Bear
That version has a transparent background. I have a version with a white background too.

Cute? Everything except for the bear was actually "drawn" in LaTeX, which I think is pretty cool. The bear is an image I found that Yahoo thought was Creative Commons (CC) licensed. I hope its particular CC license allowed for changes...

Tuesday, June 26, 2007

Most PostScript to PDF LaTeX Stuff: pst-pdf

This is a follow-up to Bounding Boxes and EPS to PDF Conversion (in LaTeX).

There is also the LaTeX package pst-pdf, which uses the tool from the package ps4pdf.

This is a clever package with a more general approach to PS-to-PDF conversion than epstopdf. Rather than focusing only on the EPS graphics, it looks at the document as a whole. This means that it takes care of converting PSTricks (CTAN, TUG) graphics as well. It's a simple way of using pdflatex to produce a PDF while using constructs inside the document that are normally only allowed with latex (I assume that psfrag/psfragx will also work well with pst-pdf).

Of course, regardless of what you are producing, you should not be using epsfig anymore; use graphics and graphicx instead. In fact, epsfig isn't even supported anymore. There is a version included with the graphicx package for backwards compatibility.

For more information about including imported EPS files in LaTeX, see epslatex.pdf.

Related post:

Bounding Boxes and EPS to PDF Conversion (in LaTeX)

Another development: More bounding box related issues are discussed in this CTT thread. It turns out that dvips -E basically guesses RANDOMLY at what the bounding box should be, and so its answers can be inconsistent. GhostScript (gs) has a bbox driver that circumscribes your EPS with a rectangle and uses the rectangular dimensions as the bounding box. The epstool command can use this GhostScript calculation to update your EPS. So you can imagine doing things like...
latex file.tex
dvips -E file.tex -o tmp.eps
epstool --bbox --copy --ouput file.eps tmp.eps
epstopdf file.eps
The epspdf script has similar functionality (when you are converting from EPS to PDF) and will be included in TeXLive 2008.

Related post: LaTeX generated figures: Using preview instead of pst-eps

Follow-up: See another interesting option (pst-pdf) in this follow-up.

Update: Another interesting option is purifyeps, which requires pstoedit and Perl. See below.

None of the following is too special. This is all well-known stuff. However, it's not the easiest to find with a Google search, so I'm going to post it here.

Pretty often, I have to generate an EPS file with MATLAB. That EPS figure will go into a LaTeX document. To generate a PDF document from my LaTeX source, I will probably use PDFLaTeX/PDFTeX. However, that means I need to convert that MATLAB EPS figure to PDF. Most EPS-to-PDF distillers I use will mess up the bounding box information and the result of the conversion will be a FULL PAGE PDF rather than the nice tiny EPS figure.

Keep this scenario in mind and consider these notes:
(*) ps2pdf command: To convert EPS to PDF and maintain the proper bounding box, try including the "EPSCrop" GhostScript (GS) option:
ps2pdf -dEPSCrop blah.eps blah.pdf
Without the -dEPSCrop option, I get the full-page PDF from a MATLAB EPS. However, with the -dEPSCrop option, things work fine.

(*) epstopdf command: ALTERNATIVELY, try this line instead:
epstopdf blah.eps
This works for me. If it doesn't, try this (on Windows with MiKTeX 2.6):
epstopdf --gsopt=-dEPSCrop blah.eps
That also works for me.

(*) epstopdf LaTeX package: You may be interested in the epstopdf package which comes with the oberdiek bundle. It should be included in your LaTeX distribution. If not, install the oberdiek bundle. You can find information (and download) about these here:
From that last link, you'll find this epstopdf usage (this will work for the graphics package as well):
\usepackage[pdftex]{graphicx}
\usepackage{epstopdf}
Then you can include graphics two different ways:
% Way 1: Includes blah.eps. Will ALWAYS generate 
% blah.pdf regardless of whether it already exists.
\includegraphics{blah.eps}

% Way 2: Includes blah.eps. If blah.pdf DOES NOT EXIST,
% it will automatically be generated.
\includegraphics{blah}
There are configuration options too. Consider the following:
% The default eps to pdf rule
\DeclareGraphicsRule{.eps}{pdf}{.pdf}{`epstopdf #1}

% Alternative eps to pdf rule
\DeclareGraphicsRule{.eps}{pdf}{.pdf}
{`ps2pdf -dEPSCrop #1}

% A rule for converting gif to png using ImageMagick
% NOTE: The placement of the % signs IS important
\DeclareGraphicsRule{.gif}{png}{.png}{%
`convert #1 `basename #1 .gif`.png%
}

% The same gif-to-png rule for Windows
% (i.e., without basename support)
\makeatletter
\DeclareGraphicsRule{.gif}{png}{.png}{%
`convert #1 \noexpand\Gin@base.png%
}
\makeatother
FINALLY, if you want to add .gif to the list of extensions that the package graphicx (or graphics package) searches if the file extension is not given in \includegraphics, you can either use the command \GraphicsExtensions OR doing something like:
\makeatletter
\g@addto@macro\Gin@extensions{,.gif}
\makeatother
Leaving the file extension off of the \includegraphics macro makes a lot of sense; however, remember that epstopdf will only be run the first time latex or pdflatex gets run. If you want it to convert all of your graphics every run, be sure to leave the extensions on.

(*) purifyeps command: There is also purifyeps, which requires pstoedit and Perl. Taken from purifyeps's CTAN page:
While pdfLaTeX has a number of nice features, its primary shortcoming relative to standard LaTeX+dvips is that it is unable to read ordinary Encapsulated PostScript (EPS) files, the most common graphics format in the LaTeX world. purifyeps converts EPS files into a "purified" form that can be read by *both* LaTeX+dvips and pdfLaTeX. The trick is that the standard LaTeX2e graphics packages can parse MetaPost-produced EPS directly. Hence, purifyeps need only convert an arbitrary EPS file into the same stylized format that MetaPost outputs.
I haven't actually played with this at all. I recommend reading purifyeps.pdf for more information about why you want a "purified" EPS rather than some other format. I assume that the bounding box problem shouldn't be an issue here, but I have no idea.

(*) pstoedit command:
MPS files can be used DIRECTLY by BOTH latex and pdflatex (pdflatex does MPS-to-PDF conversion on-the-fly). You can easily convert EPS files to MPS files yourself as long as you have psttoedit (download and install it from the pstoedit page). Take a look at section 5.4 (MetaPost) of epslatex.pdf for information on that. From the instructions there:
pstoedit -f mpost graphic.eps graphic.mp
mpost graphic.mp
rename graphic.1 graphic.mps
That is, run psttoedit to convert to MP and then use mpost to create the MPS from the MP. Simple, huh? Now, does it fix the bounding box problem? As with the last bullet, I have no idea. Maybe someday I'll try this.

Hopefully some of that will be useful to someone; it will at least be a good reference for me. :)