Most people get a sudden surprise when they need to use graphics in LaTeX as it isn't as easy as in the good old word processor. It's not hard, there are just some pitfalls, and like all pitfalls it has an elaborate description.

Today, I will start with the complex part in order to describe why the code is wrapped to make it easier for the user to import graphics, as importing graphics natively is by no means simple. To understand the issues we will have to understand a bit more about LaTeX.

In short, LaTeX is a domain specific language for typesetting documents. There are a number of compilers that read LaTeX and produce something in the other end. This something can be DVI (a device-independent format), PDF, HTML or whatever you may dream up.

When we are importing images, they are actually embedded inside PDF and PostScript files, thus a simple image could be constructed as follows in a PDF document:

40 0 obj << /Type /XObject /Subtype /Image /Width 256 /Height 256 /ColorSpace /DeviceGray /BitsPerComponent 8 /Length 82938 /Filter /ASCII85Decode >> stream ... endstream endobj

And in an HTML document it is just something simple like:

some description

Where the image actually isn't embedded in the document, but only referenced. Some people have actually thought up a way to use divs with different background colours to form an image directly in HTML, but... I wouldn't recommend that approach.

LaTeX has, in fact, not the faintest idea whatsoever about how images are embedded or included by its target formats, indeed these things are termed driver specific. Thus, it's the driver that decides what kind of image formats it supports, which is one of the main frustration points when you use LaTeX. These driver specific constructs are embedded into the output file using the \special command.

So, an obvious question is: what drivers do actually exist? The primary ‘drivers’ where images are included (DVI just carries the \special along to a ‘real’ driver without interpreting—at least most of the time) can mostly be enumerated by the target formats: PostScript and PDF. There are also other targets like provided by tex4ht that I won't go into here. So, basically, we will be concerning ourselves with PostScript and PDF.

This driver-centric approach means that if the driver doesn't understand the graphics format that you're trying to import, then it won't be displayed, and the automatic packages in LaTeX work by a conservative estimate of what most PostScript and PDF applications can handle. Thus, when we're compiling a PostScript document (using latex and dvips, for instance), we only have the choice of importing PostScript and Encapsulated PostScript documents. And when we are compiling a PDF document (using pdflatex, preferably), we only have the choice of importing PNG, JPEG and PDF. (As a side-note both formats support MPS which is MetaPost's output format, but more on that some other time).

Like in most programming-related topics, we wish to avoid tying ourselves to a single platform, so hard-coding the \special to output PostScript or PDF code is considered a bad thing. Fortunately David Carlisle has developed the graphics package that abstracts away the introduction of the \special for every image, thus making your document (more or less) portable again. We still have to remember that the formats are restricted to the driver we're using. The graphics package also includes a lot of code to do other stuff like rotate and scale images, but we'll be focusing on the \includegraphics command.

\documentclass[a4paper]{memoir} \usepackage{graphics} \begin{document} \includegraphics{mypicture.pdf} \end{document}

If we take this document and compile it using pdflatex, and have a mypicture in one of the folders that LaTeX searches when it compiles the document, we will see something like this:

Example 1

Provided that mypicture.pdf contains that lovely coloured, christmas-y snowflake. Now, sometimes the picture we wish to include in our document isn't the right size, we might want to rotate it, or only include a certain part of it. For this purpose there's an xkeyval interface to \includegraphics called graphicx. The keyval family of packages allows us to specify options to LaTeX commands in key-value pairs, like this:

\mycommand[key1=value1,key2=value2]{my arguments}

So what are the possible keys and values of the \includegraphics command? Some of the more notable are: width, height, and angle, but the full range of keys are described in the graphics package's manual. So let us look at a sample for including an image but with some fancy options:

\documentclass[a4paper,oneside]{memoir} \usepackage{graphicx} \pagestyle{empty} \begin{document} \noindent \includegraphics[angle=30,width=\textwidth]{test.pdf} \end{document}

Rotating and scaling like this results in the following result:

Example 2

The general thing to remember when including images in LaTeX is that the graphics support isn't a general image library that includes everything from BMP over TIFF to RAW. LaTeX is a document preparation system that works with a few select image formats. Plenty of tools exist to convert existing images to one of the acceptable formats (PDF, PNG and JPEG for pdflatex and PS and EPS for latex).

Good illustrations always help explain problems and solutions and can provide a deeper understanding in your audience, which, I guess, is one of the big motivations in writing (other than filling your quota of yearly publications, of course). Good illustrations take a lot of effort to produce, however, but don't be dismayed, your audience will love you for spending that time, really.