# Using macros in \DeclareGraphicsRule statement using shell command

I am currently working on a document which i am compiling under both linux and windows. As one of the images I use is a tif image, I'd like to have lualatex converting it on-runtime to a format it understands.

Therefore, I managed to do this under linux using

\DeclareGraphicsRule{.tif}{png}{.png}%
{%
convert #1 dirname #1/basename #1 .tif-tif-converted-to.png %
}
\AppendGraphicsExtensions{.tif}


This however is not portable to windows because of the dirname and basename commands (as installing ImageMagick makes convert available).

Therefore, I would like to use the file parsing from latex to do this, but I could not find my way around it. The code I am currently trying to use is :

\makeatletter
\newrobustcmd*\dirname[1]{\filename@parse{#1}\filename@area}%
\newrobustcmd*\basename[1]{\filename@parse{#1}\filename@base}%
\DeclareGraphicsRule{.tif}{png}{.png}%
{%
convert #1 \dirname{#1}/\basename{#1}-tif-converted-to.png %
}%
\makeatother
\AppendGraphicsExtensions{.tif}


However, \DeclareGraphicsRule seems to just ignore I have used macros in my command.

So my question is the following :

• What am I doing wrong ?
• Is there a way around it ?

EDIT : Slightly changing the working command

-

The conversion via shell escape is added by package epstopdf. In TeX Live it is automatically loaded, if pdfTeX/LuaTeX is detected in PDF mode and

1. LaTeX is running (plain TeX users are on their own),
2. and shell escape (\write18) is enabled (possibly restricted),
3. and \DoNotLoadEpstopdf either does not exist or is not \relax.

For convenience the package epstopdf provides a macro to define a graphics rule with conversion program (1.5.3 Conversion program):

\epstopdfDeclareGraphicsRule{.tif}{png}{.png}{%
convert #1 \OutputFile
}


Also the backtick notation with \DeclareGraphicsRule can be used:

\DeclareGraphicsRule{.tif}{png}{.png}{%
\noexpand\epstopdfcall{convert #1 \noexpand\OutputFile}%
}

• \noexpand is needd, because \DeclareGraphicsRule expands the argument.
• \epstopdfcall deals with packages like pst2pdf.

The name of the output file \OutputFile is controlled by options. Since version 2009/07/12 v2.0 the default for option suffix is

suffix=-\SourceExt-converted-to


The suffix is inserted after the base name and the new file extension. foo.tif becomes foo-tif-converted-to.png.

-
Well, it seems I did really not know the power of eps2pdf package. Thanks for this explanation, it seems to be the proper way to do it. –  Samuel Albert Aug 13 '12 at 13:44
After checking at home on my windows, it seems that your second solution doesn't work, at least under this system. You might also add in your answer that the backtick notation SHOULD NOT be used in the first (and working) solution, because it is not portable to windows. –  Samuel Albert Aug 13 '12 at 16:25
Thanks for testing. It was an error in the documentation. \epstopdfcall already adds the back tick. –  Heiko Oberdiek Aug 13 '12 at 20:40
Also make sure imagemagick is built with tiff support: convert -list configure |grep DELEGATES. –  Jens Erat Jan 26 '14 at 14:07

Macros defined with \newrobustcmd (from etoolbox) are not expanded in \write operations. However \filename@parse relies on assignments which aren't performed in those operations.

I suggest to define

\def\eattif#1.tif{#1}
\DeclareGraphicsRule{.tif}{png}{.png}{convert #1 \eattif#1-tif-converted-to.png }
\AppendGraphicsExtensions{.tif}


so that the extension will be swallowed (in an expandable fashion).

-
beat me by 45 seconds (I'll delete mine) –  David Carlisle Aug 13 '12 at 12:54
well, this seems very nice and simple. Before accepting it, i have two questions. First I'm not really sure I understand your second sentance. do you imply that \filename@parse wouldn't work anyway ? Secondly, when testing your answer I discovered that in fact, #1` doesn't seem to contain the extention under linux. Is it the same under every system (in which case it means I'm dumb and my question souldn't even be there in the first place -_-") ? –  Samuel Albert Aug 13 '12 at 13:09
Well, this was really usefull and I still would really like to hear some clarifications about your second sentence. @Heiko 's answer however seems to be the most proper way to deal with this question, so I'll accept his one instead (or should I accept both ? I really have no clue). –  Samuel Albert Aug 13 '12 at 13:39
@SamuelAlbert Surely Heiko's answer is more general. –  egreg Aug 13 '12 at 15:38