MAX-PLANCK-INSTITUT FÜR AERONOMIE
D-37191 Katlenburg-Lindau, Federal Republic of Germany
______________
Graphics and Colour with 
[This document is also available in PostScript and PDF form.]
1 Introduction
2 Importing external graphics
2.1 Importing with the graphics package
2.2 Scaling
2.3 Reflection
2.4 Rotation
2.5 Importing, scaling, rotating with the graphicx package
3 Additional graphics packages
3.1 The epsfig package
3.2 The lscape package
3.3 The rotating package
4 Troubleshooting
4.1 How importation works
4.2 Problems with importation
5 Configuring graphics importation
5.1 Default driver
5.2 Search path for graphics files
5.3 Default extensions
5.4 Graphics types
5.5 Compressing graphics files
6 Colours
7 The named colour model
MAX-PLANCK-INSTITUT FÜR AERONOMIE Graphics and Colour with [This document is also available in PostScript and PDF form.] |
With 2e, a standardized set of commands is made available for all drivers by means
of the packages graphics and color. The specialized coding to translate the user commands
into instructions for the specific drivers is placed in certain .def files which are loaded by
options to these packages. Thus one only needs to change the option to switch to another
driver; the main text remains unchanged.
The commands defined by these packages are the building blocks for other packages that
either emulate the older driver-specific ones or provide a more comfortable syntax for these
functions. As long as these other packages are based on graphics and color, they should be
equally compatible with all the supported drivers.
There are two packages available for importing and manipulating external graphics files: the
more basic graphics and the more extended graphicx. They both have identical functionality,
differing only in syntax.
In addition to the driver names, there are some other options that may be invoked when the
packages graphics or graphicx are loaded:
draft final draft; needed when the draft option has been issued globally in
\documentclass;
hidescale
hiderotate
hidescale
are useful if the previewer cannot handle scaling or rotation;
hiresbb
%%HiResBoundingBox instead of the the normal
%%BoundingBox line.graphics package graphics package is
\includegraphics[llx,lly][urx,ury]{file_name} |
[3cm, 2in])
but if they are omitted, big points (bp, 72 per inch, 28.3464. . . per cm) are assumed. If only one
optional argument is given, it is the upper right corner, and the lower left is assumed to be
[0,0].
If
no bounding box coordinates are given, the driver will obtain them some other way, depending
on the type of graphics file. For example, for the very common encapsulated PostScript files
with extension .eps, the bounding box information is extracted from the graphics file
itself. The figure at the left is stored in such a file and is included simply with the
command
\includegraphics{clock.eps} |
\includegraphics*, the figure is clipped, so that any drawing outside the
specified bounding box is suppressed. This is useful if only part of a figure is to be
reproduced. It is also vital with some perverse figures that paint the whole page
white!
\scalebox{h_scale}[v_scale]{text} |
\resizebox{h_length}{v_length}{text} |
!, the one scale factor is used for both dimensions. A *-form allows v_length to refer to
the height + depth of the box, rather than just to the height. In both cases, the
contents text may be an \includegraphics command, but it may also be any arbitrary
text.
\reflectbox{text} |
\rotatebox{angle}{text} |
To illustrate this, we have scaled the previous clock figure to
a height of 2 cm and then rotated it by 30o, using the commands
\rotatebox{30}{\resizebox{!}{2cm}{%
\includegraphics{clock.eps}}}
|
graphicx package graphicx rather than the graphics package, a different interface is available
for both importing and rotation, one making use of keys and values:
\includegraphics[key=value,. . . ]{file_name} |
true or false. Simply giving the name of a flag without a value is equivalent to setting
it to true. Possible keys and their values are:
scale= width= height not
given, it is scaled with the same factor as the width;
height= width is
not given, it is scaled with the same factor as the height;
totalheight= height but specifies the height plus depth of the figure; should
always be used in place of height if the figure has been rotated;
keepaspectratio = true/false); if both height and width are specified, this flag
ensures that the original height/width ratio remains unchanged; the figure will not
exceed either of the given dimensions;
angle= height or width specifications coming before this key are also rotated,
so that the height becomes the width, while the width becomes either the height
(positive angle) or depth (negative angle);
origin= bl for
bottom left corner; also possible are c for center, t for top, r for right, and B for
baseline; any sensible combination, such as tr, is allowed;
draft = true/false); like the draft package option but applied to the one graphics
file; the figure is not imported, but rather a framed box of the correct size is printed
containing the name of the file;
clip = true/false); suppresses the printing of any graphic outside the bounding box;
bb= bp) are assumed;
viewport= clip) to select
only a portion of the whole figure;
trim= hiresbb = true/false); like the hiresbb package option but applied to the one graphics
file; reads bounding box information from the %%HiResBoundingBox line in the
graphics file.
The keys are all optional; they are included as needed. Their order is not important other than
that angle can change previous height and width meanings. The sets of key/values are
separated from each other by commas.
With the key/value syntax, the tilted, scaled graphic on page 5 is produced with
\includegraphics[height=2cm,angle=30]{clock.eps} |
graphics package, there also exists an \includegraphics* version
that clips the imported figure; this is equivalent to including the key clip.
With the graphicx package, the \rotatebox command is similarly redefined to accept the
optional key origin.
epsfig package epsfig that not only updates the earlier (2.09)
version, but also re-implements Rokicki's epsf package by means of the graphics
commands. This is helpful for users who are accustomed to those syntaxes. For epsf, this
is
\epsfysize=y_size or \epsfxsize=x_size
\epsf[llx lly urx ury]{file_name} |
epsfig package also defines an importing command that makes use of the regular keys and
values to enter its parameters:
\epsfig{file=file_name,key=value,. . . } |
\psfig command which is synonymous
with the above.
The epsfig package is included in the bundle of graphics packages and drivers.
lscape package graphics bundle is lscape, by David Carlisle. This defines a
landscape environment that prints its contents rotated 90oon a page for itself. Head and footlines
remain as normal. This is intended primarily for inserting figures that are in landscape mode,
that is, wider than they are high.
rotating package rotating package by Sebastian Rahtz and Leonor Barroca tries to make the interface for
rotation somewhat simpler. It defines
\begin{sideways} text \end{sideways}
\begin{turn}{angle} text \end{turn}
\begin{rotate}{angle} text \end{rotate}
\turnbox{angle}{text} |
sideways rotates text by 90o, turn by an arbitrary angle. The environment rotate and
command turnbox are equivalent: they rotate but in a box of zero size, so that the contents
overlap the surroundings.
This package is not part of the graphics bundle and must be obtained separately.
has no idea what is in the graphics file; for it, the figure is simply a box of a given
height, width, and depth, as indeed are all the characters that processes. The
information on the graphic's natural size is somehow obtained, by reading %%BoundingBox line
in the graphics file itself, or in some other file, or through the optional entries in the
\includegraphics command or equivalent. After scaling and rotating, knows the final
size that it must reserve in the output text for the figure.
What is then written to the .dvi file is the name of the graphics file and information on
how it should be transformed. Just how this information is coded depends on the graphics
driver selected. When the printer driver program processes the .dvi file, it interprets these
special instructions, reads in the specified graphics file, performs the transformations, and
places the result where has said it should go. The end result is that the area inside
the designated bounding box coincides with the box that has reserved for
it. If the bounding box information is incorrect, the figure is obviously going to be
misplaced.
The most common type of graphics file to be imported is encapsulated PostScript. Files adhering to this standard are intended to be included within other PostScript files, and so must not contain certain PostScript commands that reset the whole graphics page. Most importantly, it must contain a comment line (ignored by PostScript itself) of the form:
%%BoundingBox: llx lly urx ury |
Having pointed out how the importation takes place, we can now discuss what can go wrong along this chain of processes.
|
\includegraphics command, or by editing the graphics
file itself. However, if there really is no bounding box information in the file,
it is unlikely to conform to the encapsulated standard and will cause other
problems.
and driver process without error
messages, but the figure is either displaced from the expected position, or is far too
small.
Most likely the bounding box information is incorrect. Many applications that produce PostScript files are too lazy to calculate the true bounding box, or they think they are generating a whole page with a figure somewhere in the middle. In either case, the bounding box corresponds to the full page even though the printed figure occupies only a portion of it.
Find the true bounding box by one of the following methods:
\includegraphics command, or edit the
PostScript file. In the latter case, convert to big points.
Difficulties with this are that some encapsulated PostScript files cannot be printed on their own, and that the left and bottom edges of the paper need not be the exact lines from which the printer really measures.
file such as
\setlength{\fboxsep}{-\fboxrule}
\fbox{\includegraphics{test.eps}}
|
\includegraphics command
with the viewport= key. If necessary, scale the figure down to fit on the
page, but then remember to increase the measurements by the same scale
factor.
setpagedevice.
There is little that can be done to correct this, other than trying to regenerate the graphics file with an option for encapsulated PostScript. Judicious editing can remove the troublesome lines, but this could result in the file becoming totally unreadable.
.def files, there are still a number of items that must be set up for any particular
installation and operating system. These are most conveniently placed in the local configuration
file graphics.cfg which is read in if it is present.
\ExecuteOptions{driver} |
The rest of the configuring commands in this section can be issued either in the
graphics.cfg file, or in the document.
\graphicspath{dir_list} |
searches for graphics files in the
same directories as for all other TeX files.
\DeclareGraphicsExtensions{ext_list} |
will attempt to find it
by attaching all the possible extensions. For PostScript drivers, the ext_list is usually set to
.eps,.ps. At our installation, we also include the non-standard extension .psc. Note that
the above command does not add to the list of extensions but rewrites it anew; if
you wish to add to the list, you must include all the allowed extensions in the one
declaration.
eps, encapsulated PostScript, but there do exist other types such as bmp
and pcx for other drivers. For the non-standard .psc extension above, we must also
give
\DeclareGraphicsRule{.psc}{eps}{}{} |
that this extension belongs to type eps. The other two (empty) arguments
specify that the bounding box information is to be read from the file itself, and that no other
program needs to be applied to the file.
zip or gzip programs. In such a case, the .eps file is replaced by a file with
extension .zip, or .eps.gz, or .eps-gz. Two problems now arise: first, cannot read
such files to obtain the bounding box information, and secondly, the driver needs to
unpack such a file to include it in the final output. This can be accomplished with, for
example,
\DeclareGraphicsRule{.eps.gz}{eps}{.eps.bb}{`gunzip -c #1} |
eps, with the bounding box information in the file of the
same name and extension .eps.bb, and that the operating system command gunzip -c must
be applied to the file (represented as #1). The single quote ` is required to indicate a system
command. The %%BoundingBox line of the original file must be copied and stored in the
.eps.bb file.
Such decompression rules are system dependent and thus need to be configured for the local
installation. For example, under the VMS operating system, the gzip program produces files
with extension .eps-gz and decompression is performed with gzip -d rather than with
gunzip. The corresponding rule becomes
\DeclareGraphicsRule{.eps-gz}{eps}{.bb}{`gzip -d -c #1} |
color package recognizes the options:
monochrome
dvipsnames
named colour model of dvips (Section 7) available to other drivers;
nodvipsnames
named model for dvips, to save memory;
usenames
named colours as defined ones; again, see Section 7 for details. A local configuration file color.cfg can be set up in the same way as for the
graphics package. The default driver option is specified in exactly the same way as in
Section 5.
Colours are specified either by a defined name, or by the form
[model]{specs} |
rgb (red, green, blue), cmyk (cyan, magenta, yellow, black), gray, or
named. The specs is a list of numbers from 0 to 1 giving the strengths of the components in the
model. Thus [rgb]{1,0,0} defines red, [cmyk]{0,0,1,0} yellow. The gray model takes only
one number. The named model accesses colours by internal names that were originally built into
the dvips driver, but which may now be used by some other drivers too. This model is
described in Section 7.
A colour can be defined with
\definecolor{name}{model}{specs} |
red, green, blue, yellow, cyan, magenta, black,
white.
In the following colour commands, col_spec is either the name of a defined colour, like
{blue}, or [model]{spec}, like [rgb]{0,1,0}.
\pagecolor col_spec \color col_spec \textcolor col_spec{text} \colorbox col_spec{text} \fcolorbox col_spec1col_spec2{text} \colorbox, with a frame of col_spec1 around
a box of background colour col_spec2; the two specifications must either both be
defined ones, or both use the same model, which is given only once; for example,
\fcolorbox{red}{green}{Text} sets `Text' in the current text colour on a green
background with a red frame;
\normalcolor \color command in the preamble can change the standard colour for the
whole document. This is the equivalent to \normalfont for font selection.
Normally one would try to define all the colours needed as names for the col_spec entries. This simplifies changing the colour definition everywhere should fine tuning be required after the initial printed results are seen. The same colour definition can produce quite different effects on different printers. Even the display on the monitor is no reliable guide as to how the output will appear on paper.
named colour model named and is based on the 68 predefined internal colours
of the dvips PostScript driver. Sample names are BurntOrange or DarkOrchid. This model can
be activated for other drivers with the option dvipsnames, in which case one can define colours
as, for example
\definecolor{titlecol}[named]{DarkOrchid} |
titlecol can then be used as col_spec in the various colour commands.
The named colours can be defined with their own names if one invokes the option
usenames, which effectively declares
\definecolor{BurntOrange}[named]{BurntOrange} |
It is possible to generate a palette of the named colours by processing the following short
file and sending the output to the desired printer.
\documentclass[12pt,a4paper]{article}
\usepackage[dvips]{color}
\usepackage{multicol}
\pagestyle{empty}
\setlength{\oddsidemargin}{0pt}
\setlength{\textwidth}{16cm}
\setlength{\textheight}{22cm}
\setlength{\parindent}{0pt}
\setlength{\parskip}{0pt}
\begin{document}
\renewcommand*{\DefineNamedColor}[4]{%
\textcolor[named]{#2}{\rule{7mm}{7mm}}\quad
\texttt{#2}\strut\\}
\begin{center}\Large Named colours in \texttt{dvipsnam.def}
\end{center}
\begin{multicols}{3}
\input{dvipsnam.def}
\end{multicols}
\end{document}
|