summaryrefslogtreecommitdiff
path: root/obsolete/help/texfaq/faq-graphics.tex
blob: bd90cc183cfeffbda1fe0bc46e82829ca5c19e11 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
% $Id: faq-graphics.tex,v 1.27 2014/01/22 17:29:03 rf10 Exp $

\section{Graphics}

\Question[Q-impgraph]{Importing graphics into \AllTeX{} documents}

Knuth, when designing the current version of \TeX{} back in the early
1980s, could discern no ``standard'' way of expressing graphics in
documents.  He reasoned that this state could not persist for ever,
but that it would be foolish for him to define \TeX{} primitives that
allowed the import of graphical image definitions.  He therefore
deferred the specification of the use of graphics to the writers of
\acro{DVI} drivers; \TeX{} documents would control the drivers by
means of \nothtml{\csx{special} commands (}% beware line breaks
\Qref{\csx{special} commands}{Q-specials}\nothtml{)}.

There is therefore a straightforward way for anyone to import graphics
into their document: read the specification of the \csx{special}
commands your driver uses, and `just' code them.  This is the
hair-shirt approach: it definitely works, but it's not for everyone.

Over the years, therefore, ``graphics inclusion'' packages have sprung
up; most were designed for inclusion of
\nothtml{Encapsulated \PS{} graphics (}% beware line break
\Qref{Encapsulated \PS{} graphics}{Q-eps}\nothtml{)}\nobreakspace---
which has become the \emph{lingua franca} of graphics inclusion over
the last decade or so.

Notable examples are the \Package{epsf} package (distributed with
\ProgName{dvips}) and the \Package{psfig} package.  (Both of these
packages were designed to work well with both \plaintex{} and
\LaTeXo{}; they are both still available.)  All such packages were
tied to a particular \acro{DVI} driver (\ProgName{dvips}, in
the above two cases), but their code could be configured for others.

The obvious next step was to make the code configurable dynamically.
The \LaTeX{} standard \Package{graphics} package and its derivatives
made this step: it is strongly preferred for all current work.

Users of \plaintex{} have two options allowing them to use
\Package{graphicx}: the \Package{miniltx} ``\LaTeX{} emulator'' and
the \Package{graphicx.tex} front-end allow you to load
\Package{graphicx}, and \Qref*{\Eplain}{Q-eplain} allows you to load
it (using the full \LaTeX{} syntax) direct.

The \Package{graphics} package takes a variety of ``driver
options''~--- package options that select code to generate the
commands appropriate to the \acro{DVI} driver in use.  In most cases,
your \AllTeX{} distribution will provide a \File{graphics.cfg} file
that will select the correct driver for what you're doing (for
example, a distribution that provides both \LaTeX{} and \PDFLaTeX{}
will usually provide a configuration file that determines whether
\PDFLaTeX{} is running, and selects the definitions for it if so).

The \Package{graphics} package provides a toolkit of commands (insert
graphics, scale a box, rotate a box), which may be composed to provide
most facilities you need; the basic command, \csx{includegraphics},
takes one optional argument, which specifies  the bounding box of the
graphics to be included.

The \Package{graphicx} package uses the facilities of of
\Package{graphics} behind a rather more sophisticated command syntax
to provide a very powerful version of the \csx{includegraphics}
command.  \Package{graphicx}'s version can combine scaling and
rotation, viewporting and clipping, and many other things.  While this
is all a convenience (at some cost of syntax), it is also capable of
producing noticeably more efficient \PS{}, and some of its
combinations are simply not possible with the \Package{graphics}
package version.

The \Package{epsfig} package provides the same facilities as
\Package{graphicx}, but via a \csx{psfig} command (also known as
\csx{epsfig}), capable of emulating
the behaviour (if not the bugs) the old \Package{psfig} package.
\Package{Epsfig} also supplies homely support for former users of the
\Package{epsf} package.  However, there's a support issue: if you
declare you're using \Package{epsfig}, any potential mailing list or
usenet helper has to clear out of the equation the possibility that
you're using ``old'' \Package{epsfig}, so that support is slower
coming than it would otherwise be.

There is no rational reason to stick with the old packages, which have
never been entirely satisfactory in the \LaTeX{} context. (One
irrational reason to leave them behind is that their replacement's
name tends not to imply that it's exclusively related to \PS{}
graphics.  The reasoning also excludes \Package{epsfig}, of course.)

A wide variety of detailed techniques and tricks have been developed
over the years, and Keith Reckdahl's \Package{epslatex} outlines them
in compendious detail: this highly recommendable document is available
from \acro{CTAN}.  An invaluable review of the practicalities of
exchanging graphics between sites,
% beware multiple line break problems
\begin{wideversion} % hyperversion
``\href{http://silas.psfc.mit.edu/elec_fig/elec_figures.pdf}{Graphics for Inclusion in Electronic Documents}''
\end{wideversion}
\begin{narrowversion} % non-hyper
\href{http://silas.psfc.mit.edu/elec_fig/elec_figures.pdf}%
     {``Graphics for Inclusion in Electronic Documents''}
\end{narrowversion}
has been written by Ian Hutchinson; the document isn't on \acro{CTAN},
but may also be
% beware line breaks
\href{http://silas.psfc.mit.edu/elec_fig/}{browsed on the Web}.
\begin{ctanrefs}
\item[epsf.tex]\CTANref{epsf}
\item[epsfig.sty]Part of the \CTANref{graphics} bundle
\item[epslatex.pdf]\CTANref{epslatex}
\item[graphics.sty]\CTANref{graphics}
\item[graphicx.sty]Part of the \CTANref{graphics} bundle
\item[miniltx.tex]\CTANref{graphics-plain}
\item[psfig.sty]\CTANref{psfig}
\end{ctanrefs}

\Question[Q-dvipsgraphics]{Imported graphics in \ProgName{dvips}}

\ProgName{Dvips}, as originally conceived, can only import a single
graphics format: \nothtml{encapsulated \PS{} (\extension{eps} files, }%
\Qref{encapsulated \PS{}}{Q-eps}\htmlonly{ (\extension{eps} files}).
\ProgName{Dvips} also deals with the slightly eccentric \acro{EPS} that is
created by \Qref*{\MP{}}{Q-MP}.

Apart from the fact that a depressing proportion of drawing
applications produce corrupt \acro{EPS} when asked for such output,
this is pretty satisfactory for vector graphics work.

To include bitmap graphics, you need some means of converting them to
\PS{}; in fact many standard image manipulators (such as
\ProgName{ImageMagick}'s \ProgName{convert}) make a good job of
creating \acro{EPS} files (but be sure to ask for output at \PS{}
level~2 or higher).  (\ProgName{Unix} users should beware of
\ProgName{xv}'s claims: it has a tendency to downsample your bitmap to
your screen resolution.)

Special purpose applications \ProgName{jpeg2ps} (which converts
\acro{JPEG} files using \PS{} level 2 functionality),
\ProgName{bmeps} (which converts both \acro{JPEG} and \acro{PNG}
files) and \ProgName{a2ping}/\ProgName{sam2p} (which convert a
bewildering array of bitmap formats to \acro{EPS} or \acro{PDF} files;
\ProgName{sam2p} is one of the engines that \ProgName{a2ping} uses)
are also considered ``good bets''.

\ProgName{Bmeps} comes with patches to produce your own version of
\ProgName{dvips} that can cope with \acro{JPEG} and \acro{PNG} direct,
using \ProgName{bmeps}'s conversion library.  \ProgName{Dvips}, as
distributed by \miktex{}, comes with those patches built-in, but
assuming that capability destroys portability, and is only
recommendable if you are sure you will never want to share your
document.
\begin{ctanrefs}
\item[a2ping]\CTANref{a2ping}
\item[bmeps]Distributed as part of \CTANref{dktools}[bmeps]
\item[jpeg2ps]\CTANref{jpeg2ps}
\item[sam2p]\CTANref{sam2p}
\end{ctanrefs}

\Question[Q-pdftexgraphics]{Imported graphics in \PDFLaTeX{}}

\PDFTeX{} itself has a rather wide range of formats that it can
``natively'' incorporate into its output \acro{PDF} stream:
\acro{JPEG} (\extension{jpg} files) for photographs and similar images,
\acro{PNG} files for artificial bitmap images, and \acro{PDF} for
vector drawings.  Old versions of \PDFTeX{} (prior to version~1.10a)
supported \acro{TIFF} (\extension{tif} files) format as an alternative
to \acro{PNG} files; don't rely on this facility, even if you
\emph{are} running an old enough version of \PDFTeX{}\dots{}

In addition to the `native' formats, the standard \PDFLaTeX{}
\Package{graphics} package setup causes Hans Hagen's \File{supp-pdf}
macros to be loaded: these macros are capable of translating the
output of \MP{} to \acro{PDF} ``on the fly''; thus \MP{} output
(\extension{mps} files) may also be included in \PDFLaTeX{} documents.

The commonest problem users encounter, when switching from \TeX{}, is
that there is no straightforward way to include \acro{EPS} files:
since \PDFTeX{} is its own ``driver'', and since it contains no means
of converting \PS{} to \acro{PDF}, there's no direct way the job can
be done.

The simple solution is to convert the \acro{EPS} to an appropriate
\acro{PDF} file.  The \ProgName{epstopdf} program will do this: it's
available either as a Windows executable or as a \ProgName{Perl}
script to run on Unix and other similar systems.  A \LaTeX{} package,
\Package{epstopdf}, can be used to generate the requisite \acro{PDF}
files ``on the fly''; this is convenient, but requires that you
suppress one of \TeX{}'s security checks: don't allow its use in files
from sources you don't entirely trust.

The package \Package{pst-pdf} permits other things than `mere'
graphics files in its argument.  \Package{Pst-pdf} operates (the
authors suggest) ``like \BibTeX{}''~--- you process your file using
\PDFLaTeX{}, then use \LaTeX{}, \ProgName{dvips} and \ProgName{ps2pdf}
in succession, to produce a secondary file to input to your next
\PDFLaTeX{} run.  (Scripts are provided to ease the production of the
secondary file.)

A further extension is \Package{auto-pst-pdf}, which generates
\acro{PDF} (essentially) transparently, by spawning a job to process
output such as \Package{pst-pdf} uses.  If your \pdflatex{}
installation doesn't automatically allow it~--- see % ! line break
\Qref*{spawning a process}{Q-spawnprog}~--- then you need to start
\pdflatex{} with:
\begin{quote}
\begin{verbatim}
pdflatex -shell-escape <file>
\end{verbatim}
\end{quote}
for complete `automation'.

An alternative solution is to use \ProgName{purifyeps}, a
\ProgName{Perl} script which uses the good offices of
\ProgName{pstoedit} and of \MP{} to convert your Encapsulated \PS{} to
``Something that looks like the encapsulated \PS{} that comes out of
\MP{}'', and can therefore be included directly.  Sadly,
\ProgName{purifyeps} doesn't work for all \extension{eps} files.

Good coverage of the problem is to be found in Herbert Vo\ss {}'s
\href{http://pstricks.tug.org/main.cgi?file=pdf/pdfoutput}{\acro{PDF} support page},
which is targeted at the use of \Package{pstricks} in
\PDFLaTeX{}, and also covers the \Package{pstricks}-specific package
\Package{pdftricks}.  A recent alternative (not covered in % ! line break
Herbert Vo\ss {}'s page) is \Package{pdftricks2}, which offers similar
facilities to \Package{pdftricks}, but with some useful variations.
\begin{ctanrefs}
\item[auto-pst-pdf.sty]\CTANref{auto-pst-pdf}
\item[epstopdf]Browse \CTANref{epstopdf}
\item[epstopdf.sty]Distributed with Heiko Oberdiek's packages
  \CTANref{oberdiek}
\item[pdftricks.sty]\CTANref{pdftricks}
\item[pdftricks2.sty]\CTANref{pdftricks2}
\item[pst-pdf.sty]\CTANref{pst-pdf}
\item[pstoedit]\CTANref{pstoedit}
\item[purifyeps]\CTANref{purifyeps}
\end{ctanrefs}
\LastEdit{2012-11-20}

\Question[Q-dvipdfmgraphics]{Imported graphics in \ProgName{dvipdfm}}

\ProgName{Dvipdfm} (and \ProgName{dvipdfmx}) translates direct from
\acro{DVI} to \acro{PDF} (all other available routes produce \PS{}
output using \ProgName{dvips} and then convert that to \acro{PDF} with
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}}
or \ProgName{Acrobat}'s \ProgName{Distiller}).

\ProgName{Dvipdfm}/\ProgName{Dvipdfmx} are particularly flexible
applications.  They permit the inclusion of bitmap and \acro{PDF}
graphics (as does \Qref*{\PDFTeX{}}{Q-pdftexgraphics}), but are also
capable of employing
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}} ``on the
fly'' to permit the inclusion of encapsulated \PS{} (\extension{eps})
files by translating them to \acro{PDF}.  In this way, they combine the good
qualities of \ProgName{dvips} and of \PDFTeX{} as a means of
processing illustrated documents.

Unfortunately, ``ordinary'' \LaTeX{} can't deduce the bounding box of
a binary bitmap file (such as \acro{JPEG} or \acro{PNG}), so you have
to specify the bounding box.  This may be done explicitly, in the
document:
\begin{quote}
\begin{verbatim}
\usepackage[dvipdfm]{graphicx}
...
\includegraphics[bb=0 0 540 405]{photo.jpg}
\end{verbatim}
\end{quote}
It's usually not obvious what values to give the ``\texttt{bb}'' key,
but the program \ProgName{ebb} will generate a file
containing the information; the above numbers came from an
\ProgName{ebb} output file \File{photo.bb}:
\begin{quote}
\begin{verbatim}
%%Title: /home/gsm10/photo.jpg
%%Creator: ebb Version 0.5.2
%%BoundingBox: 0 0 540 405
%%CreationDate: Mon Mar  8 15:17:47 2004
\end{verbatim}
\end{quote}
If such a file is available, you may abbreviate the inclusion
code, above, to read:
\begin{quote}
\begin{verbatim}
\usepackage[dvipdfm]{graphicx}
...
\includegraphics{photo}
\end{verbatim}
\end{quote}
which makes the operation feel as simple as does including
\extension{eps} images in a \LaTeX{} file for processing with
\ProgName{dvips}; the \Package{graphicx} package knows to look for a
\extension{bb} file if no bounding box is provided in the
\csx{includegraphics} command.

The one place where usage isn't quite so simple is the need to quote
\ProgName{dvipdfm} explicitly, as an option when loading the
\Package{graphicx} package: if you are using \ProgName{dvips}, you
don't ordinarily need to specify the fact, since the default graphics
configuration file (of most distributions) ``guesses'' the
\texttt{dvips} option if you're using \TeX{}.
\begin{ctanrefs}
\item[dvipdfm]\CTANref{dvipdfm}
\item[dvipdfmx]\CTANref{dvipdfmx}
\item[ebb]Distributed as part of \CTANref{dvipdfm}
\end{ctanrefs}
\LastEdit{2013-06-03}

\Question[Q-grffilenames]{``Modern'' graphics file names}

\TeX{} was designed in a world where file names were very simple
indeed, typically strictly limited both in character set and length.
In modern systems, such restrictions have largely disappeared, which
leaves \TeX{} rather at odds with its environment.  Particular
problems arise with spaces in file names, but things like multiple
period characters can seriously confuse the \Package{graphics}
package.

The specification of \TeX{} leaves some leeway for distributions to
adopt file access appropriate to their operating system, but this
hasn't got us very far.  Many modern distributions allow you to
specify a file name as \texttt{"file name.tex"} (for example), which
helps somewhat, but while this allows us to say
\begin{quote}
\begin{verbatim}
\input "foo bar.tex"
\end{verbatim}
\end{quote}
the analogous usage
\begin{quote}
\begin{verbatim}
\includegraphics{"gappy graphics.eps"}
\end{verbatim}
\end{quote}
using ``ordinary'' \LaTeX{} causes confusion in \ProgName{xdvi} and
\ProgName{dvips}, even though it works at compilation time.  Sadly,
even within such quotes, multiple dots give \csx{includegraphics}
difficulties.  Note that
\begin{quote}
\begin{verbatim}
\includegraphics{"gappy graphics.pdf"}
\end{verbatim}
\end{quote}
works in a similar version of \PDFTeX{}.

If you're using the \Package{graphics} package, the \Package{grffile}
package will help.  The package offers several options, the simplest
of which are \pkgoption{multidot} (allowing more than one dot in a
file name) and \pkgoption{space} (allowing space in a file name).  The
\pkgoption{space} option requires that you're running on a
sufficiently recent version of \PDFTeX{}, in \acro{PDF} mode~--- and
even then it won't work for \MP{} files, which are read as \TeX{}
input, and therefore use the standard input mechanism).
\begin{ctanrefs}
\item[grffile.sty]Distributed as part of \CTANref{oberdiek}[grffile]
\end{ctanrefs}

\Question[Q-graphicspath]{Importing graphics from ``somewhere else''}

By default, graphics commands like \csx{includegraphics} look
``wherever \TeX{} files are found'' for the graphic file they're being
asked to use.  This can reduce your flexibility if you choose to hold
your graphics files in a common directory, away from your \AllTeX{}
sources.

The simplest solution is to patch \TeX{}'s path, by changing the
default path.  On most systems, the default path is taken from the
environment variable \texttt{TEXINPUTS}, if it's present; you can adapt that
to take in the path it already has, by setting the variable to
\begin{quote}
\begin{verbatim}
TEXINPUTS=.:<graphics path(s)>:
\end{verbatim}
\end{quote}
on a Unix system; on a Windows system the separator will be ``\texttt{;}''
rather than ``\texttt{:}''.  The ``\texttt{.}'' is there to ensure
that the current directory is searched first; the trailing
``\texttt{:}'' says ``patch in the value of \texttt{TEXINPUTS} from
your configuration file, here''.

This method has the merit of efficiency (\AllTeX{} does \emph{all} of
the searches, which is quick), but it's always clumsy and may prove
inconvenient to use in Windows setups (at least).

The alternative is to use the \Package{graphics} package command
\csx{graphicspath}; this command is of course also available to users
of the \Package{graphicx} and the \Package{epsfig} packages.  The
syntax of \csx{graphicspath}'s one argument is slightly odd: it's a
sequence of paths (typically relative paths), each of which is
enclosed in braces.  A slightly odd example (slightly modified from one
given in the \Package{graphics} bundle documentation) is:
\begin{quote}
\begin{verbatim}
\graphicspath{{eps/}{png/}}
\end{verbatim}
\end{quote}
which will search for graphics files in subdirectories \File{eps} and
\File{png} of the directory in which \latex{} is running.  (Note that
the trailing ``\texttt{/}'' \emph{is} required.)

(Note that some \AllTeX{} systems will only allow you to use files in
the current directory and its sub-directories, for security reasons.
However, \csx{graphicspath} imposes no such restriction: as far as
\emph{it} is concerned, you can access files anywhere.)

Be aware that \csx{graphicspath} does not affect the operations of
graphics macros other than those from the graphics bundle~--- in
particular, those of the outdated \Package{epsf} and
\Package{psfig} packages are immune.

The slight disadvantage of the \csx{graphicspath} method is
inefficiency.  The package will call \AllTeX{} once for each entry in
the list to look for a file, which of course slows things.  Further,
\AllTeX{} remembers the name of any file it's asked to look up, thus
effectively losing memory, so that in the limit a document that uses a
huge number of graphical inputs could be embarrassed by lack of
memory.  (Such ``memory starvation'' is pretty unlikely with any
ordinary document in a reasonably modern \AllTeX{} system, but it
should be borne in mind.)

If your document is split into a variety of directories, and each
directory has its associated graphics, the \Package{import} package
may well be the thing for you; see the discussion % beware line break
\latexhtml{of ``bits of document in other directories'' (}{in the question ``}%
\Qref{bits of document in other directories}{Q-docotherdir}%
\latexhtml{)}{''}.
\begin{ctanrefs}
\item[graphics \nothtml{\rmfamily}bundle]\CTANref{graphics}
\item[import.sty]\CTANref{import}
\end{ctanrefs}

\Question[Q-graph-pspdf]{Portable imported graphics}

A regular need is a document to be distributed in more than
one format: commonly both \PS{} and \acro{PDF}.  The
following advice is based on a post by one with much experience of
dealing with the problem of dealing with \acro{EPS} graphics in this
case.
\begin{itemize}
\item Don't specify a driver when loading loading whichever version of
  the \Package{graphics} package you use.  The scheme relies on the
  distribution's ability to decide which driver is going to be used:
  the choice is between \ProgName{dvips} and \PDFTeX{}, in this case.
  Be sure to exclude options \pkgoption{dvips}, \pkgoption{pdftex} and
  \pkgoption{dvipdfm} (\ProgName{dvipdfm} is not used in this scheme,
  but the aspirant \acro{PDF}-maker may be using it for his output,
  before switching to the scheme).
\item Use \cmdinvoke{includegraphics}[...]{filename} without
  specifying the extension (i.e., neither \extension{eps} nor
  \extension{pdf}).
\item For every \extension{eps} file you will be including, produce a
  \extension{pdf} version, as described in % beware line break
  \Qref[question]{Graphics in \PDFLaTeX{}}{Q-pdftexgraphics}.  Having
  done this, you will have two copies of each graphic (a \extension{eps}
  and a \extension{pdf} file) in your directory.
\item Use \PDFLaTeX{} (rather than
  \LaTeX{}--\ProgName{dvips}--distillation or
  \LaTeX{}--\ProgName{dvipdfm}) to produce your \acro{PDF} output.
\end{itemize}
\ProgName{Dvipdfm}'s charms are less than attractive here: the
document itself needs to be altered from its default
(\ProgName{dvips}) state, before \ProgName{dvipdfm} will process it.

\Question[Q-repeatgrf]{Repeated graphics in a document}

A logo or ``watermark'' image, or any other image that is repeated in
your document, has the potential to make the processed version of the
document unmanageably large.  The problem is, that the default
mechanisms of graphics usage add the image at every point it's to be
used, and when processed, the image appears in the output file at each
such point.

Huge \PS{} files are embarrassing; explaining \emph{why} such a file
is huge, is more embarrassing still.

The \Qref*{\File{epslatex} graphics tutorial}{Q-tutbitslatex}
describes a technique for avoiding the problem: basically, one
converts the image that's to be repeated into a \PS{} subroutine, and
load that as a \ProgName{dvips} prologue file.  In place of the image,
you load a file (with the same bounding box as the image) containing
no more than an invocation of the subroutine defined in the prologue.

The \File{epslatex} technique is tricky, but does the job.  Trickier
still is the neat scheme of converting the figure to a one-character
Adobe Type~3 outline font.  While this technique is for the ``real
experts'' only (the author of this answer has never even tried it), it has
potential for the same sort of space saving as the \File{epslatex}
technique, with greater flexibility in actual use.

More practical is Hendri Adriaens' \Package{graphicx-psmin}; you load
this \emph{in place} of \Package{graphicx}, so rather than:
\begin{quote}
\begin{verbatim}
\usepackage[<options>]{graphicx}
\end{verbatim}
\end{quote}
you will write:
\begin{quote}
\begin{verbatim}
\usepackage[<options>]{graphicx-psmin}
\end{verbatim}
\end{quote}
and at the start of your document, you write:
\begin{quote}
\begin{verbatim}
\loadgraphics[<bb>]{<list of graphics>}
\end{verbatim}
\end{quote}
and each of the graphics in the list is converted to an ``object'' for
use within the resulting \PS{} output.  (This is, in essence, an
automated version of the \File{epslatex} technique described above.)

Having loaded the package as above, whenever you use
\csx{includegraphics}, the command checks if the file you've asked for
is one of the graphics in \csx{loadgraphics}' list.  If so, the
operation is converted into a call to the ``object'' rather than a new
copy of the file; the resulting \PS{} can of course be \emph{much} smaller.

Note that the package requires a recent \ProgName{dvips}, version
5.95b (this version isn't~--- yet~--- widely distributed).

If your \PS{} is destined for conversion to \acro{PDF}, either by a
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}}-based
mechanism such as \ProgName{ps2pdf} or by
(for example) \ProgName{Acrobat} \ProgName{Distiller}, the issue isn't
so pressing, since the distillation mechanism will amalgamate graphics
objects whether or not the \PS{} has them amalgamated.  \PDFTeX{} does
the same job with graphics, automatically converting multiple uses
into references to graphics objects.
\begin{ctanrefs}
\item[graphicx-psmin.sty]\CTANref{graphicx-psmin}
\end{ctanrefs}
\LastEdit{2013-06-03}

\Question[Q-grmaxwidth]{Limit the width of imported graphics}

Suppose you have graphics which may or may not be able to fit within
the width of the page; if they will fit, you want to set them at their
natural size, but otherwise you want to scale the whole picture so
that it fits within the page width.

You do this by delving into the innards of the graphics package (which
of course needs a little \LaTeX{} internals programming):
\begin{quote}
\begin{verbatim}
\makeatletter
\def\maxwidth{%
  \ifdim\Gin@nat@width>\linewidth
    \linewidth
  \else
    \Gin@nat@width
  \fi
}
\makeatother
\end{verbatim}
\end{quote}
This defines a ``variable'' width which has the properties you want.
Replace \csx{linewidth} if you have a different constraint on the width
of the graphic.

Use the command as follows:
\begin{quote}
\begin{verbatim}
\includegraphics[width=\maxwidth]{figure}
\end{verbatim}
\end{quote}

\Question[Q-topgraph]{Top-aligning imported graphics}

When \TeX{} sets a line of anything, it ensures that the base-line of
each object in the line is at the same level as the base-line of the
final object.  (Apart, of course, from \csx{raisebox} commands\dots{})

Most imported graphics have their base-line set at the bottom of the
picture.  When using packages such as \Package{subfig}, one often
wants to align figures by their tops.  The following odd little bit of
code does this:
\begin{quote}
\begin{verbatim}
\vtop{%
  \vskip0pt
  \hbox{%
    \includegraphics{figure}%
  }%
}
\end{verbatim}
\end{quote}
The \csx{vtop} primitive sets the base-line of the resulting object to
that of the first ``line'' in it; the \csx{vskip} creates the illusion
of an empty line, so \csx{vtop} makes the very top of the box into the
base-line.

In cases where the graphics are to be aligned with text, there is a
case for making the base-line one ex-height below the top of the box,
as in:
\begin{quote}
\begin{verbatim}
\vtop{%
  \vskip-1ex
  \hbox{%
    \includegraphics{figure}%
  }%
}
\end{verbatim}
\end{quote}
A more \LaTeX{}-y way of doing the job (somewhat inefficiently) uses
the \Package{calc} package:
\begin{quote}
\begin{verbatim}
\usepackage{calc}
...
\raisebox{1ex-\height}{\includegraphics{figure}}
\end{verbatim}
\end{quote}
(this has the same effect as the text-align version, above).

The fact is, \emph{you} may choose where the base-line ends up.  This
answer merely shows you sensible choices you might make.

\Question[Q-mpprologues]{Displaying \MP{} output in \ProgName{ghostscript}}

\MP{} ordinarily expects its output to be included in some context
where the `standard' \MF{} fonts (that you've specified) are already
defined~--- for example, as a figure in \TeX{} document.  If you're
debugging your \MP{} code, you may want to view it in a
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}}-based (or some
other \PS{}) previewer, but note that viewers (even
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}})
\emph{don't} ordinarily have the fonts loaded, and you'll experience
an error such as
\begin{quote}
\begin{verbatim}
Error: /undefined in cmmi10
\end{verbatim}
\end{quote}
There is provision in \MP{} for avoiding this problem: issue the
command \texttt{prologues := 2;} at the start of the \extension{mp} file.

Unfortunately, the \PS{} that \MP{} inserts in its output,
following this command, is incompatible with ordinary use of the
\PS{} in inclusions into \AllTeX{} documents, so it's best to
make the \texttt{prologues} command optional.  Furthermore, \MP{} takes a
very simple-minded approach to font encoding: since \TeX{} font
encodings are anything but simple, encoding of text in diagrams are
another source of problems.  If you're suffering such problems (the
symptom is that 
characters disappear, or are wrongly presented) the solution is
to view the `original' \MP{} output after processing through
\LaTeX{} and \ProgName{dvips}.

Conditional compilation may be done either
by inputting \File{MyFigure.mp} indirectly from a simple wrapper
\File{MyFigureDisplay.mp}:
\begin{quote}
\begin{verbatim}
prologues := 2;
input MyFigure
\end{verbatim}
\end{quote}
or by issuing a shell command such as
\begin{quote}
\begin{verbatim}
mp '\prologues:=2; input MyFigure'
\end{verbatim}
\end{quote}
(which will work without the quote marks if you're not using a Unix
shell).

A suitable \LaTeX{} route would involve processing
\File{MyFigure.tex}, which contains:
\begin{quote}
\begin{verbatim}
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\thispagestyle{empty}
\includegraphics{MyFigure.1}
\end{document}
\end{verbatim}
\end{quote}
Processing the resulting \acro{DVI} file with the \ProgName{dvips}
command
\begin{quote}
\begin{verbatim}
dvips -E -o MyFigure.eps MyFigure
\end{verbatim}
\end{quote}
would then give a satisfactory Encapsulated \PS{} file.  This
procedure may be automated using the \ProgName{Perl} script
\ProgName{mps2eps}, thus saving a certain amount of tedium.

The \plaintex{} user may use an adaptation, by
Dan Luecking, of a jiffy of Knuth's.  Dan's version
\Package{mpsproof.tex} will work under
\TeX{} to produce a \acro{DVI} file for use with \ProgName{dvips}, or
under \PDFTeX{} to produce a \acro{PDF} file, direct.  The output is
set up to look like a proof sheet.

A script application, \ProgName{mptopdf}, is available in recent
\AllTeX{} distributions: it seems fairly reliably to produce
\acro{PDF} from \MP{}, so may reasonably be considered an answer to
the question\dots{}
\begin{ctanrefs}
\item[mps2eps]\CTANref{mps2eps}
\item[mpsproof.tex]Distributed as part of the \MP{} distribution \CTANref{metapost}
\item[mptopdf]Part of \CTANref{pdftex-graphics}
\end{ctanrefs}
\LastEdit{2013-04-23}

\Question[Q-drawing]{Drawing with \TeX{}}

There are many packages to do pictures in \AllTeX{} itself (rather than
importing graphics created externally), ranging from simple use of
\LaTeX{} \environment{picture} environment, through enhancements like
\ProgName{eepic}, to 
sophisticated (but slow) drawing with \pictex{}. Depending on your type
of drawing, and setup, here are a few systems you may consider:
\begin{itemize}
\item The \environment{picture} environment provides rather primitive
  drawing capabilities (anything requiring more than linear
  calculations is excluded, unless a font can come to your help).  The
  environment's tedious insistence on its own \csx{unitlength}, as the
  basic measurement in a diagram, may be avoided by use of the
  \Package{picture} package, which detects whether a length is quoted
  as a number or as a length, and acts accordingly.
\item \Package{epic} was designed to make use of the \LaTeX{}
  \environment{picture} environment somewhat less agonising;
  \Package{eepic} extends it, and is capable of using \ProgName{tpic}
  \csx{special} commands to improve printing performance.  (If the
  \csx{special}s aren't available, the \Package{eepicemu} will do the
  business, far less efficiently.
\item \Package{pict2e}; this was advertised in % !line break
  \Qref*{the \LaTeX{} manual}{Q-latex-books}, but didn't appear for nearly
  ten years after publication of the book!  It removes all the petty
  restrictions that surround the use of the \environment{picture}
  environment.  It therefore suffers \emph{only} from the rather
  eccentric drawing language of the environment, and is a far more
  useful tool than the original environment has ever been.  (Note that
  \Package{pict2e} supersedes David Carlisle's stop-gap
  \Package{pspicture}.)
\item \pictex{} is a venerable, and very powerful, system, that draws
  by placing dots on the page to give the effect of a line or curve.  While
  this has the potential of great power, it is (of course) much slower
  than any of the other established packages.  What's more, there
  are problems with its \Qref*{documentation}{Q-docpictex}.
\item \Package{PSTricks} gives you access to the (considerable) power of
  \PS{} via a set of \tex{} macros, which talk to \PS{} using 
  \Qref*{\csx{special} commands}{Q-specials}.  Since \PS{} is itself a
  pretty powerful programming language, many astounding things can in
  principle be achieved using \Package{PSTricks} (a wide range of
  contributed packages, ranging from world mapping to lens design
  diagrams, is available).
  \Package{Pstricks}' \csx{special}s are
  by default specific to \ProgName{dvips}, but there is
  a \Package{Pstricks} `driver' that allow \Package{Pstricks} to
  operate under \xetex{}.  \PDFTeX{} users may use \Package{pst-pdf},
  which (like \Package{epstopdf}~--- see % ! line break
  \Qref[question]{\PDFLaTeX{} graphics}{Q-pdftexgraphics}) generates
  \acro{PDF} files using an auxiliary program, from \Package{PSTricks}
  commands (\Package{pst-pdf} also requires a recent installation of
  the \Package{preview} package).

  There is a \Package{PSTricks} mailing list
  (\mailto{pstricks@tug.org}) which you may
  \href{http://tug.org/mailman/listinfo/pstricks}{join}, or you may
  just browse the % ! line break
  \href{http://tug.org/pipermail/pstricks/}{list archives}.
\item \Package{pgf}: while \Package{pstricks} is very powerful and
  convenient from `traditional' \tex{}, using it with \PDFLaTeX{} is
  pretty tiresome: if you 
  simply want the graphical capabilities, \Package{pgf}, together with
  its ``user-oriented'' interface \Package{tikz}, may be a good
  bet for you.  While \acro{PDF} has (in essence) the same graphical
  capabilities as \PS{}, it isn't programmable; \Package{pgf} provides
  \LaTeX{} commands that will utilise the graphical capabilities of
  both \PS{} and \acro{PDF} equally.  \Package{Pgf} has extensive
  mathematical support, which allows it to rival \Package{PSTricks}'
  use of the computation engine within \PS{}.
  The \Package{pgf} manual is enormous, but a simple introduction which
  allows the user to get a feel for the capabilities of the system, is
  available at \url{http://cremeronline.com/LaTeX/minimaltikz.pdf}
\item \MP{}; you liked \MF{}, but never got to grips with font files?
  Try \Qref*{\MP{}}{Q-MP}~---
  all the power of \MF{}, but it generates \PS{} figures; \MP{}
  is nowadays part of most serious \AllTeX{} distributions.  Knuth
  uses it for all his work\dots{}

  Note that you can % ! line break
  \Qref*{``embed'' \MP{} source in your document}{Q-inlgrphapp} (i.e.,
  keep it in-line with your \latex{} code).
\item You liked \MF{} (or \MP{}), but find the language difficult?
  \ProgName{Mfpic} makes up \MF{} or \MP{} code for you using
  familiar-looking \AllTeX{} macros.  Not \emph{quite} the full power
  of \MF{} or \MP{}, but a friendlier interface, and with \MP{} output
  the results can be used equally well in either \LaTeX{} or \PDFLaTeX{}.
\item You liked \pictex{} but don't have enough memory or time?  Look
  at the late Eitan Gurari's \Package{dratex}: it is just as powerful,
  but is an entirely new implementation which is not as hard on
  memory, is much more readable and is (admittedly sparsely) documented at
  \url{http://www.cse.ohio-state.edu/~gurari/tpf/html/README.html},
  as well as in the author's book ``TeX and LATeX: Drawing and
  Literate Programming'', which remains available from on-line
  booksellers.
\end{itemize}

In addition, there are several means of generating code for your
graphics application (\ProgName{asymptote}, \ProgName{gnuplot} and
\MP{}, at least) in-line in your document, and then have them
processed in a command spawned from your \AllTeX{} run.  For details,
see \Qref{question}{Q-inlgrphapp}.
\begin{ctanrefs}
\item[dratex.sty]\CTANref{dratex}
\item[epic.sty]\CTANref{epic}
\item[eepic.sty]\CTANref{eepic}
\item[eepicemu.sty]\CTANref{eepic}
\item[mfpic]\CTANref{mfpic}
\item[preview.sty]\CTANref{preview}
\item[pspicture.sty]\CTANref{pspicture}
\item[pst-pdf.sty]\CTANref{pst-pdf}
\item[pgf.sty]\CTANref{pgf}
\item[pict2e.sty]\CTANref{pict2e}
\item[pictex.sty]\CTANref{pictex}
\item[picture.sty]Distributed as part of \CTANref{oberdiek}[picture]
\item[pstricks]\CTANref{pstricks}
\item[tikz.sty]Distributed as part of \CTANref{pgf}
\end{ctanrefs}
\LastEdit{2012-10-19}

\Question[Q-inlgrphapp]{In-line source for graphics applications}

Some of the free-standing graphics applications may also be used
(effectively) in-line in \latex{} documents; examples are
\begin{booklist}
\item[asymptote]The package \Package{asymptote} (provided in the
  \ProgName{asymptote} distribution) defines an environment
  \environment{asy} which arranges that its contents are available for
  processing, and will therefore be typeset (after ``enough'' runs, in
  the `usual' \latex{} way).

  Basically, you write
  \begin{quote}
    \cmdinvoke{begin}{asy}\\
    \latexhtml{\hspace*{1em}}{~~}\texttt{\meta{asymptote code}}\\
    \cmdinvoke{end}{asy}
  \end{quote}
  and then execute
\begin{quote}
\begin{verbatim}
latex document
asy document-*.asy
latex document
\end{verbatim}
\end{quote}
\item[egplot]Allows you to incorporate \ProgName{GNUplot}
  instructions in your document, for processing outside of \latex{}.
  The package provides commands that enable the user to do calculation
  in \ProgName{GNUplot}, feeding the results into the diagram
  to be drawn.
\item[gmp]Allows you to include the source of MetaPost diagrams, with
  parameters of the diagram passed from the environment call.
\item[emp]An earlier package providing facilities similar to those of
  \Package{gmp} (\Package{gmp}'s author hopes that his package will
  support the facilities \Package{emp}, which he believes is in need
  of update.)
\item[mpgraphics]Again, allows you to program parameters of \MP{}
  diagrams from your \latex{} document, including the preamble details
  of the \latex{} code in any recursive call from \MP{}.
\end{booklist}
In all cases (other than \Package{asymptote}), these packages require
that you can % ! line break
\Qref*{run external programs from within your document}{Q-spawnprog}.
\begin{ctanrefs}
\item[asymptote.sty]\CTANref{asymptote}
\item[egplot.sty]\CTANref{egplot}
\item[emp.sty]\CTANref{emp}
\item[gmp.sty]\CTANref{gmp}
\item[mpgraphics.sty]\CTANref{mpgraphics}
\end{ctanrefs}
\LastEdit*{2011-03-16}

\Question[Q-drawFeyn]{Drawing Feynman diagrams in \LaTeX{}}

Michael Levine's \Package{feynman} bundle for drawing the diagrams in
\LaTeXo{} is still available.

Thorsten Ohl's \Package{feynmf} is designed for use with current
\LaTeX{}, and works in
combination with \MF{} (or, in its \Package{feynmp} incarnation, with
\MP{}).  The \ProgName{feynmf} or
\ProgName{feynmp} package reads a description of the diagram written
in \TeX{}, and writes out code.  \MF{} (or \MP{}) can then produce a
font (or \PS{} file) for use in a subsequent \LaTeX{} run.  For
new users, who have access to \MP{}, the \PS{} version is
probably the better route, for document portability and other reasons.
% checked rf 2001/03/22

Jos Vermaseren's \Package{axodraw} is mentioned as an alternative in
the documentation of \Package{feynmf}, but it is written entirely in
terms of \ProgName{dvips} \csx{special} commands, and is thus rather
imperfectly portable.

An alternative approach is implemented by Norman Gray's \Package{feyn}
package.  Rather than creating complete diagrams as postscript images,
\Package{feyn} provides a font (in a variety of sizes) containing
fragments, which you can compose to produce complete diagrams.  It
offers fairly simple diagrams which look good in equations, rather
than complicated ones more suitable for display in figures.
\begin{ctanrefs}
\item[axodraw]\CTANref{axodraw}
\item[feyn \nothtml{\rmfamily}font bundle]\CTANref{feyn}
\item[feynman bundle]\CTANref{feynman}
\item[feynmf/feynmp bundle]\CTANref{feynmf}
\end{ctanrefs}

\Question[Q-labelfig]{Labelling graphics}

``Technical'' graphics (such as graphs and diagrams) are often
labelled with quite complex mathematical expressions: there are few
drawing or graphing tools that can do such things (the honourable
exception being \MP{}, which allows you to program the labels, in
\AllTeX{}, in the middle of specifying your graphic).

Placing `labels' on graphics produced by all those \emph{other} tools is
what we discuss here.  (Note that the term ``label'' should be
liberally interpreted; many of the techniques \emph{were} designed for
use when applying labels to figures, but they may be used equally well
to draw funny faces on a figure \dots{} or anything.

The time-honoured \Package{psfrag} package can help, if your image is
included as an (encapsulated) \PS{} file.  Place an unique
text in your graphic, using the normal text features of your tool, and
you can ask \Package{psfrag} to replace the text with arbitrary
\AllTeX{} material.  \Package{Psfrag}'s ``operative'' command is
\cmdinvoke{psfrag}{\emph{Orig text}}{\emph{Repl text}}, which
instructs the system to replace the original (``unique'') text with
the \TeX{}-typeset replacement text.  Optional arguments permit
adjustment of position, scale and rotation; full details may be found
in \File{pfgguide} in the distribution.

Since \Package{psfrag} works in terms of (encapsulated) \PS{} files,
it needs extra work for use with \PDFLaTeX{}.  Two techniques are
available, using \Qref*{\Package{pst-pdf} package}{Q-pdftexgraphics}
in a mode designed to do this work; and using \Package{pdfrack}.

The \Qref*{\Package{Pst-pdf} package}{Q-pdftexgraphics} can support
this ``extra work'' usage.  In fact, the \Package{pst-pdf} support
package \Package{auto-pst-pdf} offers a configuration setting
precisely for use with \Package{psfrag}.

If you have the `right' environment (see below), you could try the
\Package{pdfrack} script bundle.  The script aims to cut each figure
out of your source, using it to produce a small \latex{} file with
nothing but the figure inclusion commands.  Each of these figure files
is then processed to \PS{}, compiled using the \csx{psfrag} commands,
and the resulting output converted to \acro{PDF} again.

\Package{Pdfrack} is written to use the Unix Bourne shell (or
equivalent); thus your environment needs to be a Unix-based system, or
some equivalent such as \ProgName{cygwin} under windows.  (What is
more, \Package{pdfrack}'s author is rather disparaging about his
package; the present author has never tried it.)

The \Package{psfragx} package goes one step further than
\Package{psfrag}: it provides a means whereby you can put the
\Package{psfrag} commands into the preamble of your \acro{EPS} file
itself.  \Package{Psfrag} has such a command itself, but deprecates
it; \Package{psfragx} has cleaned up the facility, and provides a
script \ProgName{laprint} for use with \ProgName{Matlab} to produce
appropriately tagged output.  (In principle, other graphics
applications could provide a similar facility, but apparently none does.)

\ProgName{Emacs} users may find the embedded editor \ProgName{iTe} a
useful tool for placing labels: it's a \AllTeX{}-oriented graphical
editor written in \ProgName{Emacs Lisp}.  You create
\environment{iteblock} environments containing graphics and text, and
may then invoke \ProgName{iTe} to arrange the elements relative to one
another.

Another useful approach is \Package{overpic}, which overlays a
\environment{picture} environment on a graphic included by use of
\csx{includegraphics}.  This treatment lends itself to ready placement
of texts and the like on top of a graphic.  The package can draw a
grid for planning your ``attack''; the distribution comes with simple
examples.

The \Package{lpic} package is somewhat similar to \Package{overpic};
it defines an environment \environment{lpic} (which places your
graphic for you): within the environment you may use the command
\csx{lbl} to position \latex{} material at appropriate places over the
graphic.

\Package{Pinlabel} is another package whose author thought in the same
sort of way as that of \Package{overpic}; the documentation explains
in detail how to plan your `labelling attack'~--- in this case by
loading your figure into a viewer and taking measurements from it.
(The package discusses direct use of
\href{http://www.ghostscript.com/}{\ProgName{ghostscript}} as well as
customised viewers such as
\href{http://www.ghostgum.com.au/}{\ProgName{gsview}} or
\ProgName{gv}.)

\Package{Pstricks} can of course do everything
that \Package{overpic}, \Package{lpic} or \Package{pinlabel}
can, with all the flexibility of \PS{} programming that it offers.
This capability is exemplified by the \Package{pst-layout} package,
which seems to be a superset of both \Package{overpic} and
\Package{lpic}.

Similarly, \Package{pgf/TikZ} has all the power needed, but no
explicit package has been released.

The \Package{pstricks} web site has a page with several % ! line break
\href{http://pstricks.tug.org/main.cgi?file=Examples/overlay}{examples of labelling}
which will get you started; if \Package{pstricks} is % ! line break
\Qref*{an option for you}{Q-drawing}, this route is worth a try.

The confident user may, of course, do the whole job in a picture
environment which itself includes the graphic.  I would recommend
\Package{overpic} or the \Package{pstricks} approach, but such things
are plainly little more than a convenience over what is achievable
with the do-it-yourself approach.
\begin{ctanrefs}
\item[auto-pst-pdf.sty]\CTANref{auto-pst-pdf}
\item[gv]\CTANref{gv}
\item[iTe]\CTANref{ite}
\item[laprint]Distributed with \CTANref{psfragx}
\item[lpic.sty]\CTANref{lpic}
\item[overpic.sty]\CTANref{overpic}
\item[pdfrack]\CTANref{pdfrack}
\item[pinlabel.sty]\CTANref{pinlabel}
\item[pgf.sty]\CTANref{pgf}
\item[psfrag.sty]\CTANref{psfrag}
\item[psfragx.sty]\CTANref{psfragx}
\item[pstricks.sty]\CTANref{pstricks}
\item[pst-layout.sty]\CTANref{pst-layout}
\item[pst-pdf.sty]\CTANref{pst-pdf}
\end{ctanrefs}
\LastEdit{2013-06-03}