# Very wierd undefined control sequence error, using ctuthesis class

I'm writing a thesis at the moment and I'm using the LaTex class that my university recommends. It's called ctuthesis https://github.com/tohecz/ctuthesis. I'm also using a pacakge called gfig (https://asinus.feld.cvut.cz/geec/# -> Export -> LaTex -> Library for LaTex (gfig)), it is used for reading output files of a cuircit simulator and I have to use it. The problem is that even though I succesfully load the package, I get an Undefined control sequence error saying it doesn't recognize \gfig. It also seems wierd to me that in the .log file, this same error jumps up multiple times, even though there is only one instance of \gfig. Here is the code:

\documentclass{ctuthesis}

\usepackage{gfig}

\ctusetup{
mainlanguage = czech,
author = {Šimon Fojtík},
month = 5,
year = 2020
}

\ctuprocess

\begin{document}

\maketitle

\gfig{Circuit}
\end{document}


Now, I definitely think it's an error caused by the ctuthesis class, because gfig worked without a problem when I used article class. Also, I'm using TeXstudio and miktex. The creator of ctuthesis didnt respond to issues for a few years now, but I'm hoping it's something trivial and easy to fix. Any help is appreciated, thanks in advance.

EDIT: Here is part of the lofg file:

Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
(hyperref)                removing \ctuthesis_field_use:nn' on input line 958.

Package hyperref Warning: Token not allowed in a PDF string (PDFDocEncoding):
(hyperref)                removing \ctuthesis_field_use:n' on input line 958.
.
.
.
! Undefined control sequence.
\@calc@post@scan ...st@scan \else \def \calc@next
{\calc@error #1}\fi \fi \f...
l.18 \gfig{
Circuit}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., \hobx'), type I' and the correct
spelling (e.g., I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

! Undefined control sequence.
\GenericError  ...
#4  \errhelp \@err@     ...
l.18 \gfig{
Circuit}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., \hobx'), type I' and the correct
spelling (e.g., I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

! Undefined control sequence.
\GenericError  ...
\let \@err@               ...
l.18 \gfig{
Circuit}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., \hobx'), type I' and the correct
spelling (e.g., I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

! Undefined control sequence.
\GenericError  ...
\@empty \def \MessageBreak...
l.18 \gfig{
Circuit}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., \hobx'), type I' and the correct
spelling (e.g., I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

! Undefined control sequence.
\GenericError  ...
\endgroup
l.18 \gfig{
Circuit}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., \hobx'), type I' and the correct
spelling (e.g., I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.
.
.
.

• The gfig package uses keycommand, which is among a set of buggy packages. Apr 11 '20 at 17:17
• I hope that the creator of ctuthesis do repond here, becuse the user yo is active at this site:) Apr 11 '20 at 17:18
• @wipet The problem is with keycommand, not with ctuthesis. Apr 11 '20 at 17:20
• but why does it work with diffrent document classes? i suppose that means there isnt an easy fix? Apr 11 '20 at 17:22
• Maybe, you can generate gfigs to pdf files with another document class and then include such pdf into ctuthesis document... Apr 11 '20 at 17:24

The unrecognized control sequence is \calc@next; the error message ends with \gfig, but that's where TeX has arrived in the input file when it encountered the error.

This error is typical of situations when the calc package is loaded (which is done indirectly by ctuthesis.cls, through pdfpages) and \setlength or similar command is expanded inside \edef, which they don't survive when calc is loaded.

The keycommand package defines commands in a very fragile way; the author of gfig.sty was careful in telling keycommand to keep safe some commands, but didn't take into account \setlength, \addtolength and \setcounter that can be indeed modified by calc.

Solution. Open the gfig.sty file and change all occurrences of

\setlength    \addtolength    \setcounter


into

|\setlength|    |\addtolength|    |\setcounter|


You might want to test this version of gfig.sty that's free from the problem.

%%% gfig.sty
\RequirePackage{graphicx,xparse}

\ExplSyntaxOn
\box_new:N \l_gfig_main_box
\dim_new:N \l_gfig_xn_dim   % natural width
\dim_new:N \l_gfig_xf_dim  % scaled or imposed width
\dim_new:N \l_gfig_yf_dim  % scaled or imposed height

\NewDocumentCommand{\gfig}{O{}m}
{
\group_begin:
\keys_set:nn { gfig } { #1 }
\gfig_main:n { #2 }
\group_end:
}

\keys_define:nn { gfig }
{
width .dim_set:N = \l_gfig_width_dim,
width .initial:n = -1000pt,
scale .tl_set:N = \l_gfig_scale_tl,
scale .initial:n = 1,
hshift .dim_set:N = \l_gfig_hshift_dim,
hshift .initial:n = 0pt,
vshift .dim_set:N = \l_gfig_vshift_dim,
vshift .initial:n = 0pt,
textsize .tl_set:N = \l_gfig_textsize_tl,
}

\cs_new_protected:Nn \gfig_main:n
{
\hbox_set:Nn \l_gfig_main_box { \includegraphics{#1} }
\dim_set:Nn \l_gfig_xn_dim { \box_wd:N \l_gfig_main_box }
\mbox
{
\dim_compare:nTF { \l_gfig_width_dim = -1000pt }
{
\hbox_set:Nn \l_gfig_main_box { \includegraphics[scale=\l_gfig_scale_tl]{#1} }
}
{
\hbox_set:Nn \l_gfig_main_box { \includegraphics[width=\l_gfig_width_dim]{#1} }
}
\dim_set:Nn \l_gfig_xf_dim { \box_wd:N \l_gfig_main_box }
\dim_set:Nn \l_gfig_yf_dim { \box_ht:N \l_gfig_main_box }
\dim_set:Nn \unitlength { \fp_eval:n { \l_gfig_xf_dim/\l_gfig_xn_dim } in }
\vbox_to_ht:nn { \l_gfig_yf_dim + \l_gfig_addtoheight_dim + \l_gfig_vshift_dim }
{
\vss
\hbox_to_wd:nn { \l_gfig_xf_dim + \l_gfig_addtowidth_dim + \l_gfig_hshift_dim }
{
\skip_horizontal:n { \l_gfig_hshift_dim }
\hbox_to_wd:nn { 0pt }
{
\includegraphics[width=\l_gfig_xf_dim]{#1}
\hss
}
\l_gfig_textsize_tl
\begin{picture}(0,0)
\input{#1.ppp}
\end{picture}
}
\skip_vertical:n { \l_gfig_vshift_dim }
}
}
}
\ExplSyntaxOff

• Wow, thank you so much, this does it flawlessly. I'll let my thesis supervisor know about this, as I believe he is a co-author of gfig. Once again, thank you, this problem would set me quite a lot back. Apr 11 '20 at 18:11
• @ŠimonFojtík I prepared a new version of gfig.sty that uses expl3 and is much simpler. You may want to test it with diagrams you already have. Apr 11 '20 at 20:49
• I tried it and it works well, thanks Apr 12 '20 at 16:43
• @chips The most challenging part was the final computation of \unitlength`. The result I get is the same as the original for the first two decimal digits (which is the accuracy of that computation), so the two versions should work the same up to essentially invisible shifts of the symbols. Apr 12 '20 at 16:49