[Tex/LaTex] Pass named arguments to macro

key-valuemacros

I notice that includegraphics takes what seems to be named arguments:

\includegraphics[width=50,height=25,trim=1 2 3 4,clip]{an_img.png}

I'd like to wrap a number of my includegraphics calls in a macro, so that the following commands

\happygraphics{an_img.png}
\happygraphics{an_img.png}{rotate=90}

expand to

\includegraphics[width=50,height=25,trim=1 2 3 4,clip]{an_img.png}
\includegraphics[width=50,height=25,trim=1 2 3 4,clip,rotate=90]{an_img.png}

respectively.

I've tried using

\DeclareDocumentCommand\song{ m g }{
  \includegraphics[width=50,height=25,trim=1 2 3 4,clip,rotate=90\IfNoValueF{#2}{,#2}]{#1}
}

but I get the dreaded

! Package keyval Error: keepaspectratio,trim=0 0 0.5in 0,clip undefined.

error.

How should I go about doing this?

Best Answer

A slightly modified interface via the definition

\newcommand{\happygraphics}[2][,]{%
  \includegraphics[width=50,height=25,trim=1 2 3 4,clip,#1]{#2}}%

would allow to add options as needed to \happygraphics[<options>]{<file>}.

A similar interface is provided through xparse:

\usepackage{xparse}% http://ctan.org/pkg/xparse
\NewDocumentCommand{\happygraphics}{O{,} m}{%
  \includegraphics[width=50,height=25,trim=1 2 3 4,clip,#1]{#2}}%

The above takes advantage of supplying empty (default) key-values as ,.

Since the key-value interface is comfortable with supplying empty options (or consecutive commas ,,,...), there's no need for extra testing of the existence of an optional argument. Unless, of course, you want to do more based on whether or not the use supplied an optional argument.

Related Solutions

[Tex/LaTex] Building keyval arguments using a macro.

The keyval approaches all avoid expanding input, so in your \lstset{\flags} example the code sees \flags and not the content of the macro. The error message here is a bit unhelpful as it is expanded by TeX, so it looks like what you expect! You need to expand the input before applying the keyval macro

\documentclass{minimal}
\usepackage{listings}
\lstset{language=Pascal}
\def\flags{language=Pascal}
\expandafter\lstset\expandafter{\flags}
\begin{document}
\end{document}

(I assume the real problem has this wrapped up inside a macro or similar, where you can do the appropriate expansion.)

[Tex/LaTex] Why isn’t everything expandable

While a definitive answer can only come from the Stanford team involved in development of TeX, and from Professor Knuth in particular, I think we can see some possible reasons.

First, Knuth designed TeX primarily to solve a particular problem (typesetting The Art of Computer Programming). He made TeX sufficiently powerful to solve the typesetting problems he faced, plus the more general case he decided to address. However, he also kept TeX (almost) as simple as necessary to achieve this. While expandable macros are useful, they are not required to solve many issues.

Secondly, there are cases where an expandable approach would be at least potentially ambiguous. Bruno's \edef\foo{\def\foo{abc}} is a good case. I'd say that here the expected result with an expandable \def is that \foo expands to nothing, but I'd also say this is not totally clear. There is the much more common case where you want something like

\begingroup
\edef\x{%
 \endgroup
 \def\noexpand\foo{\csname some-macro-to-fully-expand\endcsname}%
 }
 \x

which would be made more complex with expandable primitives.

The above example points to another grey area: what would happen about things like \begingroup and more importantly \relax. The fact that the later is a non-expandable no-op is often important in TeX programming. (Indeed, the fact that \numexpr, etc., gobble an optional trailing \relax is sometimes regarded as a bad thing.)

Finally, I suspect that ease of implementation is important. The approach of having separate expansion and execution steps makes the flow relatively easy to understand, and I also suspect to implement. An approach which mixes expansion and execution requires a more complex architecture. Here, we have to remember when Knuth was writing TeX, and the fact that programming ideas which we take for granted today were not necessarily applicable in the late 1970s. A fully-expandable approach would I suspect have made the code more complex and slower. The speed impact is one that was important when TeX was running on 'big' computers.

Best Answer

Related Solutions

[Tex/LaTex] Building keyval arguments using a macro.

[Tex/LaTex] Why isn’t everything expandable

Related Question