14

The following MWE:

\documentclass{article}

\usepackage{tikz}
    \usetikzlibrary{%
        decorations.pathreplacing,
        calligraphy
    }

\begin{document}

\thispagestyle{empty}

\tikz \draw[
                ultra thick,
                decorate,
                decoration={
                    calligraphic brace,
                    amplitude=1.5mm
                }
            ](0,0) -- (4in,0);%

\end{document}

generates the following warnings:

*************************************************
* LaTeX warning: "kernel/invalid-variant"
* 
* Variant form 'nnV' invalid for base form '\spath_get:nnN'.
*************************************************
*************************************************
* LaTeX warning: "kernel/invalid-variant"
* 
* Variant form 'VnV' invalid for base form '\spath_get:nnN'.
*************************************************

This happens when the tikzlibrary calligraphy is loaded. I realize that these are just LaTeX 3 warnings (the code produces output as expected), but I would like to make sure that this is not the prelude to something more serious in the future. (MacTeX 2017, updated this morning.)

sgmoye
  • 8,586
  • 4
    Real MWE: \documentclass{article} \usepackage{tikz,spath3} \begin{document} Test \end{document} – TeXnician Jan 01 '18 at 17:08
  • Interesting. Was not familiar with spath3.sty. – sgmoye Jan 01 '18 at 17:12
  • Me neither, but the file tikzlibrarycalligraphy.code.tex hinted on that package. – TeXnician Jan 01 '18 at 17:19
  • Interesting. I don't get an error with TL2017, but I haven't updated it since I installed it so I'll try again after updating. If so, I suspect that L3 is being a bit more careful about types than it used to be and I got caught out (again). In this case, the V variants are used only in one command which you are unlikely to use except for diagnostic purposes so although it should be fixed, you needn't worry about it being a prelude to worse. – Andrew Stacey Jan 01 '18 at 17:32
  • @LoopSpace it is not an error, only a warning in the log. – Ulrike Fischer Jan 01 '18 at 17:34
  • 1
    @UlrikeFischer The warning suggests that these variants cannot be defined, so if anything later tries to use them then that won't work. In that case, I'd say that it qualifies as an error on my part. Regardless, I get neither warning nor error in my log on my system but (as I said) my system might be a bit out of date. – Andrew Stacey Jan 01 '18 at 17:37
  • Having now updated to the latest TL2017, I also get the error. I'll fix this for next time I update it on CTAN (but given that this is not a significant issue, it might not make it until I have some other bugs to fix). – Andrew Stacey Jan 01 '18 at 19:41

1 Answers1

14

I don't know if this qualifies as real answer, but here's the problem: spath3.sty (the spath3 package which seems to be a helper package for the calligraphy TikZ library) defines a control sequence \spath_get:nnN and the following variants

\cs_generate_variant:Nn \spath_get:nnN {nnV,VnN,VnV}

But this cannot work as you cannot generate a V type variant for a N argument (you could only specify V for n), which is ignored in variants one and three. This means that the package is not programmed correctly and the author should be notified.

Edit: Just to clarify what this means: The command specification of a LaTeX3 macro contains an argument specification. This denotes which type of argument is expected by the macro. N means a token like \foo, n a token list like f o o. V is a way to say that not the token \foo is what the command will get, but its value (for \def\foo{a} it would get the a).

Edit 2: As @egreg pointed out in the comments the only use of one of the suspicious variants is in spath3.sty at the following point:

\NewDocumentCommand \SPathInfoInto { m m m }
{
  \tl_set:Nn \l_tmpa_tl #3
  \spath_get:nnV {#1} {#2} \l_tmpa_tl
}

This can be fixed (even on document level) by using a redefinition with \spath_get:nnN instead of the variant. But for the warnings to disappear the package has to be updated.

TeXnician
  • 33,589
  • 1
    Thanks for the investigative work. Looking back at how I used the V variants, I think I was trying to get around an issue with excess braces. The value of the token in question was itself another token so it sort of did make sense in this case. But it looks as though the L3 team have taken a stronger stance on types so I'll have to think up another nefarious scheme to get around this problem. It's definitely not critical, though, as the command itself is used only in one place and that isn't likely to be used in production code. – Andrew Stacey Jan 01 '18 at 17:34
  • @LoopSpace We've been keen to make it clearer when people misunderstand how variants relate – Joseph Wright Jan 01 '18 at 17:43
  • @LoopSpace You're welcome. Speaking of l3 style maybe you also want to have a look at the calligraphy library again as it uses internal methods of spath (no interface level), i.e. \__spath_get. Maybe that could be replaced with the interface level function \spath_get? – TeXnician Jan 01 '18 at 17:57
  • The wrong variants are not used except in the definition of \SPathInfoInto, that can be fixed at runtime by adding, between \ExplSyntaxOn and \ExplSyntaxOff, \RenewDocumentCommand \SPathInfoInto { m m m } { \tl_set:Nn \l_tmpa_tl {#3} \spath_get:nnN {#1} {#2} \l_tmpa_tl } – egreg Jan 01 '18 at 18:05
  • @egreg Thanks for pointing this out. I've edited it in. – TeXnician Jan 01 '18 at 18:09
  • @egreg which is only worth doing if you actually use that command. I suspect that I own the only file in existence which does so. – Andrew Stacey Jan 01 '18 at 18:16
  • @TeXnician Good advice. I guess I've always thought of the calligraphy package as part of the wider spath3 library and so using internals wasn't a "bad" thing and I was optimising for speed by avoiding an unnecessary test, but you're right that it's bad style and doesn't follow good practices of separating the levels. – Andrew Stacey Jan 01 '18 at 18:17