# Which macro actually typesets images in graphicx?

I was looking through /usr/local/texlive/2015/texmf-dist/source/latex/graphics/graphicx.dtx and trying to figure out what macro actually typesets the image file.

For example, on the user level, we type

\usepackage{graphicx} % Load the graphicx.dtx file within preamble
\includegraphics{file} % Load the image file within body


But \includegraphics does a few things. I think it

• separates file name from file extension
• iterates all acceptable file extensions so that you don't have to enter it explicitly
• creates error on bad input
• etc.?

In the macro definition of \Ginclude@graphics, I found \Gin@setfile. Does this typeset the file? What mechanism determines draft mode vs non-draft mode?

The reason being is I would like to redefine or patch it to include the file name centered below the image.

# \Gin@setfile as of May 4, 2015

From /usr/local/texlive/2015/texmf-dist/tex/latex/graphics/graphics.sty

\def\Gin@setfile#1#2#3{%
\ifGin@bbox\else
eps%
\else
#1%
\fi
\endcsname{\Gin@base#2}%
\else
\Gin@nosize{#3}%
\fi
\fi
\Gin@viewport@code
\Gin@nat@height\Gin@ury bp%
\Gin@nat@width\Gin@urx bp%
\Gin@req@sizes
\expandafter\ifx\csname Ginclude@#1\endcsname\relax
\Gin@drafttrue
\@latex@error{Can not include graphics of type: #1}\@ehc
\fi
\fi
\leavevmode
\ifGin@draft
\hb@xt@\Gin@req@width{%
\vrule\hss
\vbox to \Gin@req@height{%
\hrule \@width \Gin@req@width
\vss
\edef\@tempa{#3}%
\rlap{ \ttfamily\expandafter\strip@prefix\meaning\@tempa}%
\vss
\hrule}%
\hss\vrule}%
\else
\ProvidesFile{#3}[Graphic file (type #1)]%
\setbox\z@\hbox{\csname Ginclude@#1\endcsname{#3}}%
\dp\z@\z@
\ht\z@\Gin@req@height
\wd\z@\Gin@req@width
\box\z@
\fi}

• The actual file inclusion is handed to the driver, with different code for the various engines – egreg May 4 '16 at 7:13
• the test for draft mode is \ifGin@draft with it just printing the filepath if true \else calling the back end defined code to include a file. – David Carlisle May 4 '16 at 8:13

The main part of the code you quote is

\setbox\z@\hbox{\csname Ginclude@#1\endcsname{#3}}%


which calls \Ginclude@xxx where xxx is the file type (determined from the extension or passed as an key to \includegraphics) so if xxx is eps this will call \Ginclude@eps and if the driver specified (in an option or set in graphics.cfg) is dvips then dvips.def will have been loaded which defines EPS inclusion by

\def\Ginclude@eps#1{%
\message{<#1>}%
\bgroup
\def\@tempa{!}%
\dimen@\Gin@req@width
\dimen@ii.1bp%
\divide\dimen@\dimen@ii
\@tempdima\Gin@req@height
\divide\@tempdima\dimen@ii
\special{PSfile="#1"\space
llx=\Gin@llx\space
lly=\Gin@lly\space
urx=\Gin@urx\space
ury=\Gin@ury\space
\ifx\Gin@scalex\@tempa\else rwi=\number\dimen@\space\fi
\ifx\Gin@scaley\@tempa\else rhi=\number\@tempdima\space\fi
\ifGin@clip clip\fi}%
\egroup}


Here's an implementation with a patched and redefined \includegraphics. Currently, the width of the filename is not accounted for, but one can do that by changing the T argument to F in the \stackengine argument list. The underset gap of the filename is currently 3pt. Note that the filename is generated properly, regardless of whether the extension was specified in calling argument.

EDITED to handle special characters in filename, such as underscores.

\documentclass{article}
%\usepackage[T1]{fontenc}% TO PROPERLY FORMAT UNDERSCORES IN FILENAMES
\usepackage{stackengine,graphicx,xpatch}
\makeatletter
\apptocmd{\Gin@setfile}{\xdef\file@root{#3}}{}{}
\let\svincludegraphics\includegraphics
\renewcommand\includegraphics[2][]{%
\savestack\tmp{\svincludegraphics[#1]{#2}}%
\stackengine{3pt}{\tmp}{\detokenize\expandafter{\file@root}}%
{U}{c}{F}{T}{S}% <- CHANGE T TO F TO ACCOUNT FOR FILENAME WIDTH
}
\makeatother
\begin{document}
Does it work?  \includegraphics[width=.7in]{example-image-a}

Here is another test \includegraphics[width=2.7in]{example-image-c.jpg}
\end{document}


• This addresses the actual concern of the OP. Therefore +1. – AlexG May 4 '16 at 10:41
• @AlexG Both answers are helpful! David Carlisle answered my question-in his usual minimalist fashion. Steven was nice enough to go above and beyond the question and provide a solution to one of my goals (maybe because it was fun to do? :D). Some people on this site are explanation-oriented, while some are goal-oriented. I'd like to recognize that this community has a good mix of both types of experts. So give them both +1 :) – Jonathan Komar May 4 '16 at 11:13
• @macmadness86 Thanks! The optimist sees the glass half full; the pessimist sees the glass half empty; the engineer sees the glass twice as big as necessary (or perhaps the engineer only sees the glass with a factor of safety of 2.0) – Steven B. Segletes May 4 '16 at 11:16
• @macmadness86. I did, by the way, even before Stevens answer appeared. – AlexG May 4 '16 at 11:48