Tablespecification and complex column

Question

Based on 2 former questions I have found another problem, I am not aware about that this could be a problem.

Question 1: Conditional complex column type

But I failed. If I call the command once, everything is fine. Maybe there is some bug in the tablespecification command?

\documentclass{scrreprt}

\usepackage[T1]{fontenc} % Use 8-bit encoding that has 256 glyphs
\usepackage[utf8]{inputenc} % Uses the utf8 input encoding

\usepackage{graphicx} % Required for including images
\usepackage{booktabs,array,ragged2e,multirow,colortbl}
\usepackage[table]{xcolor}
\usepackage{datatool}
\usepackage{longtable} % can be commented out, approach is an very generic method of tablespec


\providecommand{\conta}{\xspace\RIGHTarrow\xspace}
\newcolumntype{M}[1]{>{\hspace{0pt}\raggedright\arraybackslash}m{#1}}
\newcolumntype{Z}[9]{
      !{\color{#6}\vrule width #4 #7}
      >{\ifnum\pdfstrcmp{#2}{left}=0 \raggedright\arraybackslash \fi
        \ifnum\pdfstrcmp{#2}{center}=0 \centering\arraybackslash \fi
        \ifnum\pdfstrcmp{#2}{right}=0 \raggedleft\arraybackslash \fi
        \ifnum\pdfstrcmp{#2}{zero}=0 \fi
        \columncolor{#3}
        }
        p{#1 #8}
      !{\color{#6}\vrule width #5 #7}
    }


\makeatletter
\newcommand{\settablespec}[2]{%
  \toks@={}%
  \@tfor\next:=#2\do{ 
    \toks@=\expandafter{\the\expandafter\expandafter\expandafter\toks@\next} 
  } 
  \edef#1{\the\toks@} 
}
\newcommand{\tablebegin}[2]{ 
  \def\next{\begin{#1}} 
  \expandafter\next\expandafter{#2} 
}
\makeatother

    \xdefinecolor{mywhite}{rgb}{1,1,1}
    \xdefinecolor{myblack}{rgb}{1,1,1}



    \FPupn{vlinedistance}{0.2}
    \FPupn{hlinedistance}{0.2}
    \FPupn{outerlinedistance}{0.00}

\begin{document}


 \providecommand{\hlttextacs}{2.2}
 \providecommand{\hlttextbcs}{2.3}
 \providecommand{\hlttextccs}{2.2}
 \providecommand{\bheaderalacs}{left}
 \providecommand{\bheaderalbcs}{center}
 \providecommand{\bheaderalccs}{right}

    \providecommand{\AAastart}{}
    \providecommand{\AAasingle}{}
    \providecommand{\AAb}{}
    \providecommand{\AAc}{}
    \providecommand{\AAbend}{}
    \providecommand{\AAcend}{}


\renewcommand{\AAastart}{Z{\hlttextacs}{\bheaderalacs}{myblack}{\outerlinedistance}{0}{myblack}{em}{cm}{text}}
\renewcommand{\AAasingle}{Z{\hlttextacs}{\bheaderalacs}{myblack}{\outerlinedistance}{\outerlinedistance}{myblack}{em}{cm}{text}}
\renewcommand{\AAb}{Z{\hlttextbcs}{\bheaderalbcs}{myblack}{\vlinedistance}{0}{myblack}{em}{cm}{text}}
\renewcommand{\AAc}{Z{\hlttextccs}{\bheaderalccs}{myblack}{\vlinedistance}{0}{myblack}{em}{cm}{text}}
\renewcommand{\AAbend}{Z{\hlttextbcs}{\bheaderalbcs}{myblack}{0}{\outerlinedistance}{myblack}{em}{cm}{text}}
\renewcommand{\AAcend}{Z{\hlttextccs}{\bheaderalccs}{myblack}{0}{\outerlinedistance}{myblack}{em}{cm}{text}}


\providecommand{\mytablespec}[1]{
 \ifnum#1=1%
    \settablespec{\mytablespec}{%
        \AAasingle%
        }%
        \else%
        \fi%
 \ifnum#1=2%
    \settablespec{\mytablespec}{%
        \AAastart%
        \AAbend%
        }%
        \else%
        \fi%
 \ifnum#1=3%
    \settablespec{\mytablespec}{%
        \AAastart%
        \AAb%
        \AAcend%
        }%
        \else%
        \fi%
 }%


\mytablespec{2}  

\def\mytabletype{longtable}

\tablebegin{\mytabletype}{\mytablespec}
            A & CC \tabularnewline
            $D$ & DD
\end{\mytabletype}

\mytablespec{2}  


\def\mytabletype{longtable}
\tablebegin{\mytabletype}{\mytablespec}
        \specialrule{0.00em}{0.0em}{\hlinedistance em}%
A & B \tabularnewline
C & D  
\end{\mytabletype}

\end{document}

Question 1: Does anybody can see the bug? Question 2: Is there any resource for a deeper understanding of tex code which is recommended to study?

If you redefine a command \mytablespec, you cannot also continue to use it with its old definition. After you've done \mytablespec{2} once, you overwrite the definition and cannot use it in this way again. Now, it just contains the stuff for the table specification. I think. This seems excessively complicated. It is hard to believe this is a good approach since it will be extremely difficult for you to maintain code like this, won't it? — cfr, Jan 16 '16 at 04:39
@cfr calling \settablespec{\mytablespec}{% \AAasingle% }% directly wont have this effect. I can call this more than once... but if I hide this sequence in a Macro, it wont... Thanks for your reference. — Peter Ebelsberger, Jan 16 '16 at 12:14
When you say calling it once works fine, are you sure? There are easier ways to draw two black rectangles than this! — cfr, Feb 09 '16 at 23:53
It works fine for me when I don't overwrite the macro. As I say, if you redefine \mytablespec, you can't continue using it with its old definition as well. — cfr, Feb 10 '16 at 00:02

score 1 · Accepted Answer · answered Feb 10 '16 at 00:13

The problem is that the first time you call \mytablespec, \mytablespec itself is redefined. So, when you call it the second time, it has its new definition and not the old one. If you redefine a macro, you cannot continue to use it with its old definition. It now has its new definition and it can only have one definition at a time.

The problem can be easily avoided by choosing a different macro name. I've used \setmytablespec rather than \mytablespec.

Since your definitions seemed to produce nothing but black rectangles even at the best of times, I tweaked the code to do something more interesting.

I've also made the example a bit more minimal, although it could be minimised much further.

The only really significant change is

\newcommand{\setmytablespec}[1]{
...

rather than

\providecommand{\mytablespec}[1]{
...

I've also substituted \newcommand for \providecommand where applicable. \providecommand should be used really to define fall-back definitions i.e. where you want to make sure a macro has some definition, even if it hasn't been set.

\newcommand will give an error when it fails because a macro name is already taken. In most cases, either this or \renewcommand is what you want.

This wasn't causing any issues in your code and \newcommand would not have revealed the problem in this case because \edef is doing the overwriting. But it is better, I think, to use the correct variant of the macro creation commands LaTeX offers so that you do get errors (\newcommand if macro is already defined), silent ignoring (\providecommand if macro is already defined) or silent redefining (\renewcommand if macro is already defined), as appropriate. There doesn't seem any obvious reason to silently ignore an existing definition of the macros defined here.

\documentclass{scrreprt}
\usepackage[T1]{fontenc} % Use 8-bit encoding that has 256 glyphs
\usepackage[utf8]{inputenc} % Uses the utf8 input encoding
\usepackage{booktabs,array}
\usepackage[table]{xcolor}
\usepackage{datatool}
\usepackage{longtable} % can be commented out, approach is an very generic method of tablespec

\newcommand{\conta}{\xspace\RIGHTarrow\xspace}
\newcolumntype{M}[1]{>{\hspace{0pt}\raggedright\arraybackslash}m{#1}}
\newcolumntype{Z}[9]{
  !{\color{#6}\vrule width #4 #7}
  >{\ifnum\pdfstrcmp{#2}{left}=0 \raggedright\arraybackslash \fi
    \ifnum\pdfstrcmp{#2}{center}=0 \centering\arraybackslash \fi
    \ifnum\pdfstrcmp{#2}{right}=0 \raggedleft\arraybackslash \fi
    \ifnum\pdfstrcmp{#2}{zero}=0 \fi
    \columncolor{#3}
  }
  p{#1 #8}
  !{\color{#6}\vrule width #5 #7}
}

\makeatletter
\newcommand{\settablespec}[2]{%
  \toks@={}%
  \@tfor\next:=#2\do{
    \toks@=\expandafter{\the\expandafter\expandafter\expandafter\toks@\next}
  }
  \edef#1{\the\toks@}
}
\newcommand{\tablebegin}[2]
{
  \def\next{\begin{#1}}
  \expandafter\next\expandafter{#2}
}
\makeatother

\FPupn{vlinedistance}{0.2}
\FPupn{hlinedistance}{0.2}
\FPupn{outerlinedistance}{0.00}

\begin{document}
\newcommand*{\hlttextacs}{2.2}
\newcommand*{\hlttextbcs}{2.3}
\newcommand*{\hlttextccs}{2.2}
\newcommand*{\bheaderalacs}{left}
\newcommand*{\bheaderalbcs}{center}
\newcommand*{\bheaderalccs}{right}

\newcommand{\AAastart}{Z{\hlttextacs}{\bheaderalacs}{cyan!50!blue!25}{\outerlinedistance}{0}{cyan!50!blue}{em}{cm}{text}}
\newcommand{\AAasingle}{Z{\hlttextacs}{\bheaderalacs}{blue!50}{\outerlinedistance}{\outerlinedistance}{blue}{em}{cm}{text}}
\newcommand{\AAb}{Z{\hlttextbcs}{\bheaderalbcs}{magenta!25}{\vlinedistance}{0}{magenta}{em}{cm}{text}}
\newcommand{\AAc}{Z{\hlttextccs}{\bheaderalccs}{green!50!black!25}{\vlinedistance}{0}{green!25!black}{em}{cm}{text}}
\newcommand{\AAbend}{Z{\hlttextbcs}{\bheaderalbcs}{yellow!30}{0}{\outerlinedistance}{orange}{em}{cm}{text}}
\newcommand{\AAcend}{Z{\hlttextccs}{\bheaderalccs}{blue!50!green!25}{0}{\outerlinedistance}{blue!50!green!75!black}{em}{cm}{text}}

\newcommand{\setmytablespec}[1]{
  \ifnum#1=1%
  \settablespec{\mytablespec}{%
    \AAasingle%
  }%
  \fi%
  \ifnum#1=2%
  \settablespec{\mytablespec}{%
    \AAastart%
    \AAbend%
  }%
  \fi%
  \ifnum#1=3%
  \settablespec{\mytablespec}{%
    \AAastart%
    \AAb%
    \AAcend%
  }%
  \fi%
}%

\setmytablespec{2}

\def\mytabletype{longtable}

\tablebegin{\mytabletype}{\mytablespec}
A & CC \tabularnewline
$D$ & DD
\end{\mytabletype}

\setmytablespec{2}

\def\mytabletype{longtable}
\tablebegin{\mytabletype}{\mytablespec}
\specialrule{0.00em}{0.0em}{\hlinedistance em}%
A & B \tabularnewline
C & D
\end{\mytabletype}

\setmytablespec{3}

\def\mytabletype{longtable}
\tablebegin{\mytabletype}{\mytablespec}
\specialrule{0.00em}{0.0em}{\hlinedistance em}%
A & B &E \tabularnewline
C & D &F
\end{\mytabletype}

\setmytablespec{1}

\def\mytabletype{tabular}
\tablebegin{\mytabletype}{\mytablespec}
\specialrule{0.00em}{0.0em}{\hlinedistance em}%
E  \tabularnewline
F
\end{\mytabletype}

\end{document}

I cannot compile this MWE.
Underfull \vbox (badness 100000) detected at line 103 )

! Emergeny stop. (*) ./tablespec.tex

No pages of output — Peter Ebelsberger, Feb 10 '16 at 11:05
@PeterEbelsberger I just copied the code back and it (still) compiles fine for me. I do get 2 underful \vboxes, These are caused by the uses of \specialrule in the two relevant cases. I don't know what this command does or where it is defined, but its use in two of the tables leads to the underfull boxes in these cases. That has nothing to do with the emergency stop you are getting. You would need to figure out what is causing the *error* (not warning) in that case. Since it works for me, I can only say: you have different code or different versions or need to remove generated files. — cfr, Feb 11 '16 at 02:13
Did you compile *exactly this code* as a *new* .tex document? If so, then add \listfiles and post the list of files you get so that we can compare versions. — cfr, Feb 11 '16 at 02:15
I tried to compile once more and I cannot explain why, but it compiles without any error. Hm... dont understand why, but it works. :) no more need of support. You mentioned that there is an much easier method to do this tasks. Is it worth to think about it? — Peter Ebelsberger, Feb 11 '16 at 11:30
Well, you may. But I don't know what the purpose of all this is. That is, just specifying tables in the usual way seems easier to me. This seems a very complex way of saying \begin{tabular}{<spec>} or \begin{longtable}{<spec>}. I don't really see the point ;). — cfr, Feb 11 '16 at 16:38
The point is. This piece of code is part of a command, which takes 9 arguments, table head or nothing, label, caption, width of each columns, alignment of each columns, tooltip, and some 2 more arguments to change table outside an one argument for providing a csv file. I only want to have one command, which takes some arguments and makes multipage tables, taking a csv file. This piece of code enables me to do the part of alignment as well as change tabletype from longtable to (for exampel) supertabular in combination with datatool or csvsimple. (including individual design) — Peter Ebelsberger, Feb 11 '16 at 19:07
At the very least, I'd use a key-value interface for that. But perhaps you are better at remembering the order, type and meaning of 9 arguments than I am. In any case, as far as I can tell, this answered your question. But I guess you are dissatisfied, though it is not entirely clear to me why. — cfr, Feb 11 '16 at 20:21
I am absolutley satisfied. I was thinking about your message that the solution can be made much easier. I am willing to lern more and so I was willing to hear other solution, even if your provided MWE works exactly as expected. — Peter Ebelsberger, Feb 11 '16 at 21:50
@PeterEbelsberger Oh, OK. I see. Fair enough. I would use a key-value interface unless the code is being automatically generated, in which case it doesn't matter how difficult it is to remember to order and form of arguments. But I would only do this at all if I had many, many tables to do. Otherwise, the loss of transparency in the source code easily outweighs any saving in terms of input. — cfr, Feb 11 '16 at 22:07

Tablespecification and complex column

1 Answers1