I want to recreate my current makros to work in every document. Currently I am working on the task, if a package is loaded, the command will be provided as desired.

Look at the following MWE, which works as expected.




\providecommand{\pkgldxcolortxt}{Package xcolor not loaded or missing}

% Comment this package in or out to see what will happen.
% \usepackage{xcolor}

            \renewcommand{\pkgldxcolortxt}{Package loaded}

        \providecommand{\test}[1]{Need Package xcolor}
    \providecommand{\test}[1]{\textbf{#1}} % or \providecommand{\test}{} if you don't want to access anything
    \providecommand{\textcolor}[2]{Sorry, xcolor not loaded, you tried to make #2 in color #1}

\item \test{A}
\item \textcolor{red}{text}
\item \pkgldxcolortxt

If you comment out xcolor, the example still compiles. If you set the debugflag, you will see, why the command wont work as expected.

This is a very primitive example of check if package is loaded and tell the command how to work.

My question: Is there any better way to achieve this solution? Second question would be, if there is any nice way of inputvalidation for commands like



In this case the command will work every time I compile and there is no way, that there is a wrong behaviour for the command.

Would that be a good idea?

  • You're using \color instead of \textcolor. Note that \color{red} is a declaration telling to start coloring text in red, whereas \textcolor{red}{text} will only color “text”.
    – egreg
    May 4 '15 at 21:25
  • You are right, have corrected the MWE. May 4 '15 at 21:26
  • What do you mean by “validate”? Checking if the input is characters only?
    – egreg
    May 4 '15 at 21:28
  • The first aproach is only to execute commands which can be executed if the corresponding package is loaded. This is my way to archive this. The other question is, if I know the required input command (for example if I know, that only a-z and A-Z is allowed, and only 10 characters will be accepted not to destroy the layout of the document (for example) than it would be nice to prevent the input from any user.... Or otherwise (on argument will be passed as an option and there are only 5 options allowed (and if no one will be selected, default should be used automatically)... May 4 '15 at 21:32
  • Isn't this too much overhead? Couldn't you not just load (or \RequirePackage the relevant package?
    – user31729
    May 4 '15 at 21:40

Introducing \setboolean{pkgldxcolor}{true} and then testing that boolean serves no purpose, why not simply use

      {% do nothing
      {% define \textcolor etc

but in this case it seems you don't really need a test at all, you could \usepackage{xcolor} or if you do not want to force color to be loaded, just have

  Sorry, xcolor not loaded, you tried to make #2 in color #1}

which doesn't need to be guarded by a package loaded test as it will simply do nothing of color is loaded and has defined \textcolor.

  • But the definition of \test does depend on the package loaded, doesn't it? In the non-debug case, it is supposed to print its argument in bold if colour is not available.
    – cfr
    May 4 '15 at 23:35
  • @cfr I'd just define \test as \textcolor{red}{\textbf{#1}} always and just make the \providecommand of \textcolor handle the non color case, making it print text as above, or make a warning, or silently do nothing depending on requirements. May 4 '15 at 23:40
  • So would I: I just meant that this is a further feature of the original example. (I'm assuming it may be meant to do something not obvious from the minimal case, but maybe not.)
    – cfr
    May 4 '15 at 23:47
  • @DavidCarlisle If I have serveral commands, which requires different packages than the boolean enables me to check different packagestates.... so if some more packages has to be added, all states can be gathered and used for the macros...... Think about the following.... package xcolor Package longtable on macro requires ONLY xcolor, the other one both.... So, my idea the first marco checks boolean xcolor only, the other one checks both wie \AND .... May 5 '15 at 7:27
  • @cfr you are absolutley right (first and third...comment) May 5 '15 at 7:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.